Workflow

Worker checks for changes at a configured interval and processes each source separately. Configuration saved in Web is loaded at the next cycle, so a connection never changes in the middle of a cycle.

1. 01Detect a change

   A trigger in the business database records which row changed in its local Queue.

2. 02Coalesce notices

   Worker reads new notices and combines multiple notices for the same record.

3. 03Read the current value

   It reads the current business row instead of replaying the value from each old notice.

4. 04Select routes

   It identifies the origin and resolves enabled rules and mappings.

5. 05Check for conflicts

   It compares the previous values with both current states and validates converted values.

6. 06Apply safely

   It verifies the delivery was not already applied, writes the result, and saves processing state.

Checkpoint advances only after every rule in the batch is settled. A transient failure keeps the current position so the next cycle retries from the same place.

A Queue entry says that a record changed. It does not contain a full historical event. Worker reads the current record when it processes the notice and converges the destination on that state.

When a record is deleted

If the destination changed after the previous synchronization, SynCo does not silently delete it. Deletion is handled as a record-level conflict: keep or delete the record.

SyncCoordinator is designed to converge the current state of data. Use an event-preserving integration method for approvals, stock movements, journal entries, and other data where every intermediate action matters.

A conflict exists when both systems changed the same field from the previous saved value and produced different results. If only one side changed, that value is applied automatically.

Manual resolution

1. Compare valuesReview incoming and current destination values side by side.
2. Select the resultChoose either value or enter a value for each conflicting field.
3. Request resolutionWeb stores a resolution request instead of writing directly to the business database.
4. Verify and applyWorker reads the destination again and applies only if it has not changed.

If the destination changes while the conflict screen is open, Worker does not overwrite it. The console shows the latest value and asks for a new decision.

Worker stores read position and delivery state in databases. After shutdown or failure, it resumes remaining work without applying completed deliveries twice.

Held: Conflict holds can be resolved from the console. Manual rerun for non-conflict validation or conversion holds is not currently available.

Pause and resume

While paused, neither the Queue nor Checkpoint moves. After resume, Worker reads current values for notices that accumulated and catches up to the latest state.

Pause is an operational action intended for later resume. Disabling a system or rule removes it from synchronization configuration and is a different operation.

Synchronization should continue when a notification endpoint is temporarily unavailable. Worker first saves events to the management database, then a separate delivery loop sends webhooks.

Webhook failure does not stop synchronization. Delivery is attempted up to seven times, including the first attempt, with delays of 1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours, and 12 hours. Receivers can deduplicate with Event ID.

Use the management console to verify progress, find failures or held work, and manage webhook endpoints and delivery history.