6.1.5. ALM for AI in Dynamics 365 Finance and Supply Chain
💡 First Principle: Finance and Supply Chain Management do not use the Dataverse solution model for their own application artifacts. They are cloud-hosted apps with scheduled service updates, deployable packages, and feature management flags — so the architect's ALM design here governs configuration and release validation, not solution promotion.
The administration surface moved, and the exam is written after the move. Since 16 February 2026, new cloud implementation projects can no longer be created in Lifecycle Services for Dynamics 365 Finance, Supply Chain Management, and Project Operations. New customers use the Power Platform admin center for environment and project management, as part of the One Dynamics One Platform consolidation.
⚠️ Exam Trap: Both extreme answers are wrong. Naming Lifecycle Services as the place to start a new Finance implementation is out of date — that is the Power Platform admin center now. But "LCS is retired" is equally wrong: existing projects continue to run, and LCS is still required for Dynamics 365 Commerce, AX 2012 upgrades, on-premises implementations, and tenant-to-tenant migrations. Read the scenario for which of those it is.
What the architect actually manages:
| Element | Mechanism | ALM consideration |
|---|---|---|
| AI feature availability | Feature management flags, per environment | Enabling a feature is a change that needs promotion and validation, not a switch someone flips in production |
| Application changes | Deployable packages applied to environments | Packaged, versioned, and applied through the environment's release process |
| Configuration and parameters | Data entities for export and import | Per legal entity — the same feature may need different parameters in each |
| Platform service updates | Scheduled by Microsoft | You do not choose the code; you choose when to validate it. AI-dependent processes need a regression pass on each update |
| Power Platform integration layer | Dataverse solutions, dual-write | This half does follow 6.1.1's solution rules |
Legal entities are the unit that catches people out. A single environment hosts many legal entities with different rules, and an AI feature validated in one is not thereby validated in another — the 6.1.3 scenario of Copilot reconciliation suggestions colliding with French GAAP is exactly this. Configuration promotion must preserve entity-specific values rather than overwrite them with the source entity's.
Cross-app solutions are dual-track by necessity. When a solution spans F&SCM and a Dataverse-based app, the two follow different cadences and different mechanisms, so the ALM design needs a coordination layer: shared data entities re-tested whenever either side updates, and consistency checks that both apps still agree about the same customer or product.
Troubleshooting Scenario: A company enables an AI-assisted vendor-invoice matching feature in Finance. It was validated in a sandbox against one legal entity and behaves correctly there. In production it is enabled tenant-wide and immediately produces poor matches for three of eight legal entities. The defect is not the model — it is the ALM design: feature management was treated as a deployment switch rather than a promotable configuration, and per-entity parameters were never part of the promotion. The fix is to make feature flags and entity parameters explicit, versioned artifacts, and to validate per legal entity rather than per environment.
Reflection Question: A Finance customer starting a brand-new implementation in 2026 asks where to create their project and how AI feature configuration should flow from sandbox to production. Answer both, and say which parts of their process would differ if they were instead a Dynamics 365 Commerce customer.
