How Unit4's metadata-driven extension model — FlexiFields, Browsers, Excelerator, workflow and screen configuration — translates into D365's X++ extension model, Power Platform and Chain of Command, and why D365's fixed-data-model constraint is the price of continuous updates.
Unit4's development model is, by design, a "configure, do not code" system. FlexiFields add fields through metadata. Browsers define queries through a screen designer. Excelerator binds Excel to data through configuration. Workflows route through a routing table. Custom screens are assembled through a form designer.
Unit4's extension model operates across seven surfaces, each with a different migration cleanliness profile:
D365 F&O's architecture is built on a two-layer model: standard application (Microsoft-owned, continuously updated) and extensions (customer and partner-owned, additive). The rule is absolute: extensions add new artefacts alongside standard objects; they never modify standard objects.
Power Platform is not a fallback for things D365 cannot do. For a significant proportion of Unit4 extension patterns, Power Platform is the correct architectural choice.
Extension models are X++ projects in Visual Studio, stored in source control (Azure DevOps Git or GitHub). Builds compile models into deployable packages using Azure DevOps pipelines or GitHub Actions.
Privilege — the smallest unit: access to a single form, entity, report or menu item with a specific access level (read, update, create, delete, correct). Duty — a group of privileges representing a business responsibility ("Maintain vendor invoices").
Unit4's extension model is predominantly configuration-driven, with a high migration cleanliness for FlexiFields, Browsers, Excelerator-read and Workflow. D365's extension model is code-driven, additive and governed by a strict no-overlayering rule. The learning curve is real, and the programme must invest in it early.