Skip to main content

Conflict Resolution

Applies to: Pro · Enterprise
Last updated: 17-Jul-2025

Overview​

When multiple people edit the same schedule simultaneously, conflicting changes are inevitable. Kazinex handles conflicts automatically using last-write-wins (LWW) as the base strategy, supplemented by domain-specific rules that warn you about potentially impactful concurrent edits.

How Conflicts Are Detected​

The conflict resolver maintains a sliding window of 50 recent local operations. When a remote change arrives from another peer, the resolver compares it against your recent local operations to check for overlap.

A conflict is detected when:

  1. Both you and a peer edited the same field on the same entity at roughly the same time.
  2. A remote change affects a critical-path field that may invalidate your current view.
  3. A remote change deletes an entity you're currently editing.

Conflict Rules​

Kazinex applies five built-in conflict rules:

1. Same-Field Concurrent Edit​

PropertyValue
Applies toActivities
ConditionBoth you and a peer changed the same field on the same activity
SeverityInfo
ResolutionThe remote value is accepted (last-write-wins)
Message"Both you and a peer edited [field] on the same activity. The remote value was accepted (last-write-wins)."

This is the most common conflict type. Yjs CRDTs guarantee that all peers converge on the same final value.

2. Critical-Path Field Changed​

PropertyValue
Applies toActivities
ConditionA peer changed a field that affects the critical path
SeverityWarning
Message"A peer changed the critical-path field [field]. You may want to recalculate the schedule (F9)."

Monitored fields: Early Start, Early Finish, Late Start, Late Finish, Total Float, Free Float, Driving Path Flag, Original Duration, Remaining Duration.

3. Relationship Deleted While Editing​

PropertyValue
Applies toRelationships
ConditionA peer deleted a relationship you were editing
SeverityError
Message"A relationship you were editing was deleted by another peer."

4. WBS Node Moved Concurrently​

PropertyValue
Applies toWBS
ConditionBoth you and a peer moved the same WBS node
SeverityWarning
Message"Both you and a peer moved the same WBS node. The remote move was accepted."

5. Calendar Concurrent Edit​

PropertyValue
Applies toCalendars
ConditionBoth you and a peer edited the same calendar
SeverityWarning
Message"Both you and a peer edited the same calendar. Please review the calendar settings."

Severity Levels​

SeverityMeaning
InfoA merge occurred automatically. No action needed.
WarningA merge occurred, but you should review the result or recalculate.
ErrorSomething unexpected happened — an entity you were working on no longer exists.

Resolution Strategies​

The resolver can apply four resolution strategies:

StrategyDescription
Accept RemoteThe remote peer's value wins (used in LWW merges)
Accept LocalYour local value wins (not used by default rules)
MergeBoth values are combined (used for compatible additions)
WarnBoth values are accepted via LWW, and you're notified about the conflict

All five built-in rules use the Warn strategy — changes are merged via Yjs CRDTs, and you receive a notification explaining what happened.

How to Respond to Conflict Notifications​

  1. Info notifications — no action needed. The merge was automatic and safe.
  2. Warning notifications — review the affected entity. For critical-path warnings, press F9 to recalculate the schedule.
  3. Error notifications — the entity you were editing was deleted. Check with the other peer before re-creating it.

Tips & Best Practices​

  • Divide work by WBS area to minimise same-field conflicts between peers.
  • Recalculate after bulk changes — press F9 after a peer makes structural edits to refresh the critical path.
  • Use permissions to prevent conflicts — if a peer only needs to update progress, set them to "Status Updater" so they can't change dates or logic.
  • Communicate via the chat before making breaking changes like WBS moves or relationship deletions.