# SyteLine ION BOD Integration Go-Live Checklist

> Source: https://netray.co/tools/syteline-ion-bod-integration-go-live-checklist
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Setup, scope, testing, cutover and hypercare checks for BOD based integrations between SyteLine or CSI 10 on-prem and Infor ION.

## Category

syteline

## Erp

Infor SyteLine

## Audience

- Integration developer
- ERP administrator
- Integration project lead

## Tool

**Kind:** checklist

**Groups:**

#### Setup

**Items:**

**Text:** Logical ID for each SyteLine site agreed and matching what ION expects

**Critical:** true

ION connection point for SyteLine created and active in ION Desk

**Text:** Replication rules for BOD output enabled for each site, with the correct categories

**Critical:** true

**Text:** Replication triggers regenerated on Replication Management after every rule or category change, per site, with no other users logged in

**Critical:** true

Services that move BODs between SyteLine and the ION connection point configured and running as described in the ION integration guide for your release

Retention of processed BODs in the Replication Document Outbox and Inbox chosen deliberately where your release offers the option (useful during testing)

#### Scope

**Items:**

List every outbound BOD noun and verb in scope (for example Sync ItemMaster, Sync CustomerPartyMaster) with the receiving application

List every inbound BOD in scope and the SyteLine processing it triggers

Inbound AES handlers documented for BodPreReceive, BodOnReceive and BodOnReceiveFail where used; a failing BodPreReceive handler stops the BOD before BodOnReceive fires

**Text:** Master data load sequence agreed with the receiving application's integration guide before any transactional BODs flow

**Critical:** true

#### Testing

**Items:**

**Text:** Each outbound BOD seen in Replication Document Outbox after the triggering change

**Critical:** true

Same BOD seen delivered in ION OneView with the expected document flow

Outbox checked for Confirm BODs, which SyteLine generates when it fails to process an inbound BOD

Inbound BOD processed flag set and expected data visible on the SyteLine form

Failure path tested: a deliberately bad BOD raises the BodOnReceiveFail handler alert

Replication Tool used to view, correct and resubmit a failed request document

LogMonitor shows no replication or BOD processing errors while reproducing each scenario

#### Cutover

**Items:**

**Text:** Order for pausing and resuming document flows in ION agreed and written down

**Critical:** true

Expected BOD volume for initial loads estimated and ION and SyteLine services sized for it

Owners named on both sides for monitoring during cutover weekend

Rollback decision point and criteria agreed

#### Hypercare

**Items:**

**Text:** Daily review of Replication Document Outbox and Inbox backlog for the first weeks

**Critical:** true

Daily ION OneView check for errors and unacknowledged documents

LogMonitor reviewed for replication and BOD processing errors when a backlog appears

Replication Errors form checked for inbound records that failed on the target

Lessons learned added to the runbook before hypercare closes

**Scoring Note:** Critical items are the ones that stop BODs silently: triggers not regenerated after a rule change, logical IDs that do not match ION, master data loaded out of order, and no one watching the outbox after go-live.

## Content

**Intro:** This checklist takes a BOD integration between SyteLine or CSI 10 on-prem and Infor ION from setup to hypercare. It suits CRM, WMS, EPM, localization and other ION connected applications that exchange BODs with SyteLine.

**Sections:**

#### How to use it

**Body:** Run Setup and Scope during build, Testing in each test cycle, and Cutover and Hypercare in the go-live plan. Treat each BOD in scope as its own row in the testing group: export to Excel and add one line per noun so you can see which have passed end to end. Keep the exported checklist as part of the integration runbook, because the same checks are what support uses when a flow stops months later.

#### Where this lives in SyteLine

**Body:** Outbound BODs are generated through replication rules and categories, with triggers that must be regenerated on Replication Management after every change. Generated documents appear in Replication Document Outbox, inbound ones in the inbox, and the ION connection point exchanges them with ION. Inbound processing can be extended with application event handlers on BodPreReceive, BodOnReceive and BodOnReceiveFail. The Replication Tool on the utility server views, corrects and resubmits request documents.

**Bullets:**

- Replication Rules and categories: what generates BODs
- Replication Management: Regenerate Replication Triggers
- Replication Document Outbox: outbound BODs and Confirm BODs
- LogMonitor: replication and BOD processing errors

#### Version differences and gotchas

**Body:** Regenerating triggers drops and recreates trigger code, so do it with users out of the database and separately at each site. A Confirm BOD in the outbox means SyteLine failed to process an inbound BOD and is reporting that error back, not that delivery succeeded. Whether processed BODs stay in the outbox depends on retention settings, so an empty outbox can mean success or a setting. The recommended master data load order depends on the receiving application, so take it from that application's integration guide.

#### How to check the result in the system

**Body:** Change one record that should generate a BOD, then follow it: Replication Document Outbox in SyteLine, the document in ION OneView, and the record in the receiving application. For inbound, send one BOD, check the processed indicator and the SyteLine form, make sure no Confirm BOD was generated, and watch LogMonitor for errors. Repeat for the failure path.

**Cta:** If you want people to ask what happened to an order across SyteLine and connected applications in plain English on your own servers, we can build that layer.

**Faq:**

#### Does SyteLine have an ION API?

**Answer:** SyteLine exchanges business documents with ION as BODs, and its IDO REST endpoints can be exposed to external callers through ION API Gateway with OAuth2 service accounts. BODs suit event driven document flows between applications; the IDO API suits direct reads and method calls. Many integrations use both.

#### Why is no BOD generated after I change a replication rule?

**Answer:** Replication triggers must be regenerated on Replication Management after any change to rules or categories, and separately at each site. Until then the database triggers still reflect the old setup. Regeneration drops and recreates trigger code, so schedule it when no other users are logged in.

#### What does a Confirm BOD in the outbox mean?

**Answer:** A Confirm BOD in the SyteLine outbox is generated when SyteLine could not process an inbound BOD, and it carries the error back to the sender through ION. Open it to read the error, fix the data, setup or mapping, and have the document resent or resubmitted. During testing, keep processed BODs where your release allows it.

#### How do I handle inbound BOD failures in SyteLine?

**Answer:** Add an application event handler on BodOnReceiveFail to alert the integration owner, and use BodPreReceive to validate before processing; if a BodPreReceive handler fails, the BOD is not processed and BodOnReceive does not fire. Then use the Replication Tool to view, correct and resubmit the failed document.

## Search terms

syteline ion api, syteline ion integration, syteline bod, csi 10 ion bod, integration with erp systems, infor ion connection point, syteline replication document outbox

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