Skip to main content

Onboard a new integration

Outcome. A new external system calls Lattice in production with its own identity and the narrowest role it needs, after its calls were proven without posting, and the operators watch it from its first day. Who takes part: Integration developer, Integration administrator, Integration operator. Stages that use standard pages (Microsoft Entra ID applications, Assign users to roles, the standard Business events catalog) need System administrator or the access named on the role page; the Lattice roles do not open them. How often: once per integration. The client is registered again in each environment it runs in.

1. Choose what to call (Integration developer)​

Start from the business process, not the API: the operations that post or act, the entities that read or load data, and the events that tell your system about changes. If the partner sends files, start from a ready-made intake bundle.

Done when: you have a list of the operations, entities and events the integration uses, and you know which operations write, so the administrator can choose its role.

2. Review the contracts and design the calls (Integration developer)​

Read each request, response and payload before you write code, and decide how your system calls: with its own keys or D365 ids, one document per call or many, synchronously or in the background.

Done when: you have the sample request, or a Postman collection, for every operation on your list, and you know which members each request requires.

3. Register the client (System administrator, Integration administrator)​

A System administrator gives the integration its own identity and role in the test environment, an Integration administrator adds any setup its calls depend on, and the developer receives the tenant ID, client ID and secret.

Done when: the client is on Microsoft Entra ID applications with its user and role, and the developer has its IDs and secret; for files, Test connection on Review and create reported all checks passed.

4. Build and test without posting (Integration developer)​

Prove each call in the test environment before anything posts: a preview for the operations that have one, the simulator for files, and the call log for what really happened. An operation without a preview can only be tested by posting, so do that in the test environment.

Done when: your first preview or test posting is on Service call log and CalledBy in LatticeServiceCallLogs is the client's dedicated user; each operation with a preview returns PreviewApplied true; each test posting succeeds and a resend with the same RequestId posts nothing; every File ingestion simulator step shows Succeeded; and your endpoint receives each event you subscribed to.

5. Cut over to production (System administrator, Integration administrator, Integration developer)​

In production, a System administrator registers the client again with the narrowest role and activates the events it consumes, an Integration administrator sets up its logging, keys and file jobs, and the developer then points the client at production.

Done when: the first production posting is on Service call log with Preview clear and a Document ID, and, for files, the first file is on the Bundles tab of Inbound message inquiry with its records Processed on Segments.

6. Start monitoring (Integration operator)​

Tell the operators the integration is live, which operations and files it uses and who owns the client. From now on its failures reach them through the daily check and the alerts.

Done when: the integration's operations have rows on Service call statistics after the next daily rollup, and the operators include it in Monitor integrations every day.

If something goes wrong​