What Is SyteLine Replication?
Also known as: replication rules, site replication, intranet replication
Definition
SyteLine replication is the built-in mechanism that copies data between sites and databases in a multi-site installation. Replication categories define what moves, replication rules define where it goes, and the framework queues and delivers changes between site databases.
SyteLine Replication Explained
In a multi-site SyteLine landscape, some data should be shared and some should stay local. Customers, vendors, items, and chart of accounts often need to exist identically everywhere. Jobs, inventory, and shop transactions belong to the site that owns them. Replication is how the system reconciles those needs: it identifies changed records in defined categories and propagates them to the sites configured to receive them, either within one database or across separate databases and servers.
Configuration has three parts. Replication categories group the tables and columns for a business object such as an item or a customer. Replication rules connect a source site to one or more target sites for a given category, with options for the direction and the interval. The site and intranet definitions describe the physical topology - which databases exist, how they reach each other, and the transport used. Modern releases lean on SQL Server messaging infrastructure rather than file-based transfer.
Operationally, the two things to watch are queue depth and failed messages. When a target site is unreachable or a record violates a constraint at the destination, the message sits in a queue. If nobody monitors it, sites drift apart quietly, and the first symptom is usually a user at one plant insisting an item exists while a user at another swears it does not. Add queue monitoring to the standard operations runbook on day one of any multi-site deployment.
The design mistake that causes the most pain is over-replicating. Teams replicate more than necessary because it feels safer, then discover the volume creates latency and the shared records prevent sites from maintaining genuinely site-specific values. Replicate the minimum that the business truly requires to be identical, keep planning parameters site-specific, and document explicitly which fields are mastered where. That document becomes the reference every replication support ticket eventually needs, and writing it during design costs a fraction of reconstructing it later.
Why It Matters
- Replication is what makes multi-site SyteLine coherent; without it each plant is effectively a separate ERP.
- Unmonitored replication queues cause silent data drift between plants that is expensive and disruptive to reconcile.
- Over-replication creates latency and blocks legitimate site-specific parameter differences such as lead time and safety stock.
- Replication topology directly constrains cloud migration options, since not every on-premises pattern maps to multi-tenant cloud.
In Practice
Establish a weekly reconciliation that counts key master records - items, customers, vendors - per site and flags divergence. A count mismatch is the earliest visible symptom of a stalled replication queue, and catching it in a week rather than a quarter is the difference between a config fix and a data remediation project.
Frequently Asked Questions
What is the difference between SyteLine replication and ION integration?
Replication is an internal SyteLine mechanism for keeping data consistent between sites of the same application, typically at table and column level. ION is a cross-application integration broker that moves standardized BOD documents between different products. Use replication for SyteLine-to-SyteLine site consistency, and ION when SyteLine must exchange business documents with LN, M3, EAM, or non-Infor systems.
How do I troubleshoot data that is missing at one SyteLine site?
Check the replication queue for pending or failed messages first, then confirm a replication rule actually exists linking the source site to that target for the relevant category. Verify the record was changed at the mastering site rather than locally. Constraint violations at the destination - a missing product code or currency, for example - are a frequent cause of stuck messages.
Related Terms
Multi-Site (SyteLine)
Multi-site in SyteLine is the architecture that lets one installation run several plants, warehouses, or legal entities as distinct sites - each with its own inventory, planning, and transactions - while sharing master data and consolidating financially.
Infor ION
Infor ION is the integration backbone of Infor OS. It routes BOD messages between Infor applications such as SyteLine, LN, and M3 and third-party systems, and adds document flows, workflow, event alerts, and a monitored, replayable message trail.
Item Master
The item master in SyteLine is the central record that defines every part the business buys, makes, stocks, or sells - carrying identity, units of measure, planning parameters, costing method, product code, and quality attributes that drive nearly every downstream transaction.
Go Deeper
SyteLine Version End-of-Life Risk Assessment
Score your exposure to running an aging or unsupported SyteLine version across support, security, compliance, and skills dimensions.
SyteLine ION API Integration Guide
Step-by-step SyteLine ION API integration guide: API gateway setup, OAuth 2.0 tokens, BODs vs IDO endpoints, and secure on-prem to cloud connections.
SyteLine 9 to 10 Upgrade: Step-by-Step Guide
Plan your SyteLine 9 to 10 upgrade with this step-by-step guide: Mongoose framework changes, FormSync customization merges, timelines, costs, and testing.
Working with SyteLine Replication in a live environment? Our engineers do this every day - and our AI agents automate most of it.