# SyteLine Multi-Site Replication Health Checklist > Source: https://netray.co/tools/syteline-multi-site-replication-health-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Configuration, data, service, queue and post-upgrade checks that keep SyteLine 9 and CSI 10 on-prem multi-site replication healthy. ## Category syteline ## Erp Infor SyteLine ## Audience - ERP administrator - SQL Server DBA - Multi-site controller ## Tool **Kind:** checklist **Groups:** #### Configuration **Items:** **Text:** Sites and entities exist on the Sites and Sites/Entities forms, with linked server names, database names and intranets correct **Critical:** true **Text:** A replication rule is enabled for each source and target site pair on Replication Rules, with the right categories **Critical:** true **Text:** Triggers regenerated on Replication Management after every rule or category change, separately at each site **Critical:** true Linked servers exist for transactional rules; trigger regeneration stops with an error until they do Intranets form: the To Site's intranet has a URL defined when it differs from the From Site's intranet #### Data checks **Items:** New records created at a source site appear in the corresponding _all tables at the target site **Text:** Spot check shared master data (items, customers, vendors) across sites for missing or stale rows **Critical:** true Find Replication Setup Issue form run for any object that is not replicating, then List Issues reviewed #### Services **Items:** **Text:** Replication options set on the Replication tab of Service Configuration Manager and saved to the service configuration file **Critical:** true Replication related services running on the utility server Service Configuration Manager run and saved before the Replication Tool is used, so the tool reads current settings LogMonitor checked for ReplQListener errors while reproducing a replicated change #### Queues **Items:** **Text:** Replication Document Outbox and Inbox backlog counted and compared with yesterday **Critical:** true Replication Errors form reviewed for inbound records that were retrieved but failed at the target Failed records corrected and resubmitted from Replication Errors (successful updates are removed from ShadowValuesErrors) Replication Tool used to view, correct and resubmit failed inbound or outbound request documents Linked site status checked in the Replication Tool #### After upgrades or restores **Items:** **Text:** Triggers regenerated at every site after an upgrade, update or database restore **Critical:** true Linked servers and remote site settings revalidated after a server rename or restore One test transaction per replication category made and followed to each target site Replication Errors and outbox cleared of backlog created during the outage #### Monitoring **Items:** Daily backlog count recorded per site Alert threshold set for backlog and error counts Named owner for replication health and a deputy Runbook links to this checklist and the Infor replication troubleshooting topics for your release **Scoring Note:** Critical items cover the failures that let sites drift apart without anyone noticing: missing rules, triggers not regenerated after changes or restores, and backlogs that nobody counts. Run the whole list after every upgrade and the Queues and Monitoring groups daily. ## Content **Intro:** This checklist keeps SyteLine 9 and CSI 10 on-prem multi-site replication healthy, built from the forms and utilities Infor documents for replication troubleshooting. Run it daily in short form and in full after any upgrade, restore or rule change. **Sections:** #### How to use it **Body:** Export the checklist to Excel and keep one copy per site. Daily, tick Queues and Monitoring and record the backlog count. After any rule change, upgrade, update or restore, run every group. When a user reports data missing at another site, start with Find Replication Setup Issue for that object and target site, then the Replication Errors form, then the Replication Tool. Do not add steps that are not in your release documentation; replication setup is sensitive to unsupported changes. #### Where this lives in SyteLine **Body:** Site relationships are defined on Sites and Sites/Entities, replication rules and categories on Replication Rules, and triggers are regenerated from Replication Management. Replication options are set on the Replication tab of Service Configuration Manager. Inbound records that failed at the target are listed on the Replication Errors form, where they can be fixed and resubmitted. The Replication Tool on the utility server views, corrects and resubmits request documents and shows linked site status. **Bullets:** - Replication Rules: source and target pairs, categories - Replication Management: Regenerate Replication Triggers - Replication Errors: failed inbound records - Find Replication Setup Issue: why an object does not replicate #### Version differences and gotchas **Body:** Regenerating triggers drops and recreates trigger code, must be run at each site, and should be done with other users out of the database. Restores and upgrades can leave triggers or linked server definitions out of step with the rules. Transactional rules need linked servers before triggers can be regenerated. Intranet URLs matter when sites sit on different intranets. Form labels can differ slightly between SyteLine 9 and CSI 10, so match them to your release help. #### How to check the result in the system **Body:** Create or change a test record in one category at a source site, then confirm it at each target site, including the _all table that carries cross-site rows. Watch LogMonitor for ReplQListener messages while you do it. Check Replication Errors stays empty and the outbox backlog returns to its normal level. **Cta:** If controllers and planners need answers across all your SyteLine sites in plain English, we can set up a private AI layer on your own servers that reads every site. **Faq:** #### What kind of system is SyteLine? **Answer:** SyteLine, also sold as CloudSuite Industrial (CSI), is Infor's ERP for discrete and mixed-mode manufacturers, built on the Mongoose framework and SQL Server. On-prem installations support multiple sites in one or several databases, with replication rules that share master data and transactions between sites. #### How does SyteLine CSI 10 replicate data between sites? **Answer:** Replication rules on the Replication Rules form define which categories of data flow from a source site to a target site. Database triggers, generated from Replication Management, capture changes, and replication services deliver them. Failures surface on the Replication Errors form and in the Replication Tool, and ReplQListener messages appear in LogMonitor. #### When do I need to regenerate replication triggers? **Answer:** After every change to replication rules or categories, and after upgrades, updates or restores that may have replaced trigger code. Regeneration drops and recreates the triggers, so run it at each site with other users logged out. For transactional rules, linked servers must exist first or the process stops with an error. #### How do I fix a record that failed to replicate? **Answer:** Open the Replication Errors form at the target site, read the error for the failed inbound record, correct the cause and resubmit; successful updates are removed from the error list. For request documents, use the Replication Tool on the utility server to view, correct and resubmit, and check linked site status. ## Search terms syteline csi 10, syteline 10 erp, syteline erp, syteline multi-site replication, syteline replication rules, regenerate replication triggers, syteline replication tool --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json