Skip to main content

Take a Lattice or Finance and Operations update

Outcome. The environment runs the new Lattice package, or the Lattice package built for its new Finance and Operations version, and every integration works as before: catalogs refreshed, background processes running, data projects mapped and a smoke test passed without posting anything. Who takes part: Integration administrator, Data management consultant, Integration developer, Integration operator. Stages that use standard pages (Process automations, the Siren pages, the Data management workspace, 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: per release, in each environment, a test environment before production.

1. Plan the update (Integration administrator, Integration developer)​

Read the changelog for the release and note every change to an operation, entity or event your integrations use. For a Finance and Operations update, take the Lattice package built for the version you are moving to: each release ships one package per supported Finance and Operations version.

Done when: you have the package for the Finance and Operations version the environment will run, and a list, possibly empty, of the changes that affect your integrations, each with an owner.

2. Record the baseline (Data management consultant, Integration operator)​

While the environment still runs the old version, capture its data management configuration, check its mappings and note the monitoring numbers, so that anything that differs afterwards is the update's doing. The data management checks are service operations with no page: call them from your pipeline or an HTTP client.

Done when: diffSpec with your committed file returns Differences 0, validateMappings with your projects' name pattern returns Success true, and the operator has noted the Integration operations tile counts and Queue status.

3. Deploy the package (Integration administrator)​

Upload and apply the package in Lifecycle Services or the Power Platform admin center. The deployment synchronizes the database, and the synchronization registers the Lattice background processes.

Done when: Lifecycle Services or the Power Platform admin center reports the deployment as completed.

4. Refresh the catalogs and check the background processes (Integration administrator, System administrator)​

Nothing refreshes the service, OData and business event catalogs on its own, and until the service metadata refresh has run, the Service test console cannot run an operation. Then check that the Lattice processes are registered and running, and that the license reads as you expect.

Done when: the Service metadata refresh log shows a refresh after the deployment with no errors, an event's Last refreshed on the Business event catalog is after the deployment, Catalog status on the OData entity metadata explorer reads Last refresh with the entity count you expect, and every Lattice ... process is listed, and not switched off, on the Background processes tab of Process automations.

5. Bring data management in step (Data management consultant, Integration administrator)​

Refresh the entity list so data management sees new and changed entities, then validate the mappings again. Refresh the mappings the update left behind, which needs the Integration administrator, and compare the environment with your configuration file once more.

Done when: validateMappings returns Success true with every warning reviewed, diffSpec returns Differences 0 (or only differences you then applied or captured into the file), and Recurring integration health shows no job Broken.

6. Smoke test without posting (Integration developer, Integration administrator)​

Prove the integrations still work without writing anything: send the posting operations you use in preview mode, run a status query, and compare the request and response samples with the ones you built against. Only postGeneralJournal, postIntercompanyJournal, confirmSalesOrder, postSalesPackingSlip, invoiceSalesOrder and their batch variants have a preview; another operation with a PreviewMode member returns ErrorCode 10, so test it by posting in a test environment. Where you can post, in a test environment, also make one business moment happen for each event you consume, because a preview raises no event.

Done when: each preview returns Success true and PreviewApplied true, each preview and test posting is on the Service call log (the previews with Preview set; a status query is never logged), and your endpoint received each event you triggered.

7. Resume daily monitoring (Integration operator)​

Run the daily check on the day of the update and compare it with the numbers you noted in stage 2, so a regression is caught at once instead of being reported by the business.

Done when: the Integration operations workspace tiles and Queue status show the numbers you noted before the update, or lower.

If something goes wrong​