# Resolving SyteLine multi-site replication conflict errors

> Source: https://netray.co/erp-help/syteline-replication-conflict-error
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

A replication conflict in SyteLine's multi-site architecture means the same record (commonly an item, customer, or BOM) was changed independently at two sites between replication cycles, and the replication engine could not automatically merge the two versions. Check the replication conflict log first to see which record and which fields collided, then decide which site's version should win before resuming the queue.

## Kind

error

## System

syteline

## Erp

Infor SyteLine (CloudSuite Industrial)

## Module

Multi-site Replication

## Query

SyteLine replication conflict error row was already changed

## Alternate Queries

- SyteLine intersite replication failed conflict
- CSI replication agent error conflicting update
- SyteLine multi-site sync conflict resolution
- SyteLine replication queue stuck

## Applies To

SyteLine 8.x/9.x multi-site (intersite replication), CloudSuite Industrial multi-site configurations

## Steps

### Identify and clear a replication conflict

**Items:**

Open the replication monitor/conflict viewer (Administration > Replication, or the specific multi-site administration form depending on version) to see the queued and failed transactions.

Identify the exact record (item number, BOM, customer, etc.) and field(s) in conflict - the conflict log shows both the source and destination values that collided.

Determine which site's change should be authoritative based on business process - usually the site that owns master data for that record type (e.g. engineering site owns BOM masters) should win.

Manually resolve the conflicting record via the conflict resolution tool if available in your version, choosing which version to keep or merging field-by-field.

If the queue is stuck rather than just showing a conflict (transactions piling up, not processing), check the replication service/agent is actually running on both sites and that connectivity (VPN, firewall, DB link) between site databases is up.

After resolving, manually re-run or release the held transaction so replication resumes, then verify downstream records that depended on the conflicting record synced correctly afterward.

To prevent recurrence, review which sites have edit rights to shared master data (items, BOMs, customers) - the root cause is usually two sites both having edit access to a record type that should be owned by one site.

## Sections

### Why multi-site replication conflicts happen

**Body:**

SyteLine's multi-site model replicates changes between site databases on a schedule or trigger rather than sharing one database in real time (except for genuinely shared/company-level tables). If both sites have update rights to the same table, and a user at each site edits the same record before the next replication cycle runs, the engine detects two divergent changes to the same row and cannot automatically decide which one is correct - it queues the transaction as a conflict rather than silently overwriting data.

This is most common with items, BOMs, routings, and customer/vendor master records that multiple sites can technically edit, especially right after go-live when site-level data ownership has not been clearly assigned yet.

### Reading the conflict log correctly

**Body:**

The conflict record typically shows the field-level before/after values from each site's change, plus timestamps. Compare timestamps to understand which change happened first chronologically at each site - but chronological order does not automatically mean it is the correct one to keep, since business ownership matters more than timing.

If the conflict involves a quantity or status field on a transactional record (like a job or order) rather than master data, treat it more carefully - blindly picking one side can silently lose a real transaction (a receipt, a status change) that the business needs, not just a data sync artifact.

### Preventing repeat conflicts

**Body:**

The durable fix is almost always a data governance one: restrict edit rights for shared master tables (items, BOMs, generic customers/vendors) to a single owning site, and have other sites treat that data as read-only, relying on replication to receive updates rather than making local edits. Document this ownership model so new users do not accidentally create edit conflicts.

**Code:**

- -- Example: check which sites recently touched a conflicting item record
- SELECT item, site_ref, last_maint_dt, last_maint_user
- FROM item WHERE item = 'ITEM-1001';

## Pitfalls

Resolving a conflict by always keeping the 'newest' timestamp without checking whether that discards a real business transaction rather than a duplicate edit.

Not checking whether the replication service/agent itself is down before assuming every stuck transaction is a genuine data conflict - a dead service just looks like a growing queue.

Ignoring recurring conflicts on the same record type - that is a sign of a data ownership/permissions problem, not a one-off glitch.

Resolving the conflict in the UI but forgetting to check for dependent records (a BOM conflict can leave downstream job routings out of sync) after resolution.

Assuming replication conflicts are rare enough to handle manually forever - at scale, unclear site ownership of master data causes repeated conflicts that erode trust in the data.

## Ai Angle

For a multi-site SyteLine customer, ERPray can watch the replication conflict log as a source and flag a new conflict with a plain-language summary (which record, which fields, which site's value is which) the moment it appears, and even suggest a resolution based on the documented site data-ownership rules already stored for that company, cutting the time an admin spends decoding the raw conflict record.

## Faq

### Does a replication conflict mean data was lost?

**Answer:** Not by itself - the conflicting transaction is held, not discarded, until someone resolves it. Data loss only happens if the conflict is resolved incorrectly (picking the wrong side) without checking what each change actually represented.

### Can replication conflicts be prevented entirely?

**Answer:** Mostly yes, by restricting edit rights on shared master data (items, BOMs, customers/vendors) to a single owning site so other sites only ever receive replicated updates rather than making conflicting local edits.

### What is the difference between a conflict and a stuck replication queue?

**Answer:** A conflict is a specific transaction the engine flagged because two sites changed the same record. A stuck queue is usually an infrastructure issue - the replication service or agent is down, or connectivity between site databases failed - and transactions simply are not processing at all.

### Who should decide which side of a conflict wins?

**Answer:** Whoever owns the business process for that data, not IT alone - for example, engineering typically owns BOM/item master conflicts, while a site's own transactional data (job status, receipts) should usually be preserved as-is rather than overwritten by another site's version.

## Search terms

syteline replication conflict, syteline multi-site sync error, syteline intersite replication failed, csi replication queue stuck, syteline conflict resolution tool, syteline multi-site data ownership, syteline replication agent down, syteline row already changed error

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json