Resolving SyteLine multi-site replication conflict errors
SyteLine replication conflict error row was already changed
Also searched as
- SyteLine intersite replication failed conflict
- CSI replication agent error conflicting update
- SyteLine multi-site sync conflict resolution
- SyteLine replication queue stuck
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.
Applies to: SyteLine 8.x/9.x multi-site (intersite replication), CloudSuite Industrial multi-site configurations
Identify and clear a replication conflict
- 1Open the replication monitor/conflict viewer (Administration > Replication, or the specific multi-site administration form depending on version) to see the queued and failed transactions.
- 2Identify 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.
- 3Determine 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.
- 4Manually resolve the conflicting record via the conflict resolution tool if available in your version, choosing which version to keep or merging field-by-field.
- 5If 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.
- 6After 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.
- 7To 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.
Why multi-site replication conflicts happen
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
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
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.
-- 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';
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Does a replication conflict mean data was lost?
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?
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?
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?
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.
Related
Fixing SyteLine's 'Object reference not set to an instance of an object' error
This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.
Error fixDiagnosing and fixing SyteLine session timeout errors
SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.
Error fixTroubleshooting SyteLine MRP and APS regeneration that fails or hangs
A SyteLine MRP or APS run that fails to complete, hangs indefinitely, or errors partway through is most often caused by data integrity problems (a BOM loop, an item with an invalid lead time or missing routing), a scheduling engine (APS) process that is stuck or resource-starved, or a concurrent MRP run conflict. Check the MRP/APS log first for the specific item or job it stopped on before assuming it is a system capacity issue.
Error fixFixing SyteLine's 'transaction out of balance' GL posting error
This posting error means SyteLine tried to create a general ledger journal entry where total debits do not equal total credits, which the GL will not accept. The most frequent causes are a missing or misconfigured account in the automatic account determination setup (COA mapping), currency rounding on multi-currency transactions, or a source transaction (inventory, job cost, AP/AR) that only partially calculated its cost or tax components before posting.
How-toHow to Run a Cost Rollup in SyteLine
Run Item Cost Rollup from Product Definition > Costing > Cost Rollup, select the site and item range, run it in Simulate mode first to review variances, then run it live to post new standard costs to Item records and the Costed Bill of Material.
How-toHow to Close a Job Order in SyteLine
Close a job order from Production > Job Orders once every routing operation is reported complete and the finished quantity has been received, then run Close Jobs to post the remaining WIP balance to variance and lock the job from further transactions.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
AI for ERPAI Agents Over Infor ION API, BODs, and the Infor Data Lake
Build AI agents on Infor ION API Gateway, BODs, and Data Lake, alongside or instead of Infor's own GenAI features, with your choice of model and hosting.
Stuck on Infor SyteLine (CloudSuite Industrial)?
Talk to engineers who work inside Infor SyteLine (CloudSuite Industrial) every week, and who build private AI that answers these questions from your own ERP data.