Fusion SaaS extensibility mapped to D365 X++ and the extension model
How Fusion's six SaaS extensibility surfaces — Descriptive Flexfields, Extensible Flexfields, Application Composer, Groovy scripting, VBS, and Page Composer — map to D365's X++ compiled metadata model, Chain of Command extensions, Power Platform, and the no-overlayering discipline that governs all D365 development.
What you will be able to do
Explain the architectural difference between Fusion's declarative SaaS extension model and D365's X++ compiled metadata model
Apply the triage matrix to classify each Fusion extensibility surface and its D365 target
Describe the no-overlayering discipline and how Chain of Command replaces method overriding
Identify what Fusion practitioners gain and what they lose when moving to D365 development
Introduction
Fusion Cloud is Software-as-a-Service. Oracle owns and operates the application infrastructure; customers extend it through declarative surfaces — Flexfields, Application Composer, Groovy scripts, Page Composer — that survive Oracle's quarterly updates without customer intervention.
Fusion's six extensibility surfaces
Oracle Fusion exposes six surfaces for customer extensions, in increasing order of migration complexity.
D365's extension model: X++, Chain of Command, and Power Platform
All D365 application objects — tables, classes, forms, enums, data types — live in the Application Object Tree. Microsoft's objects are in Microsoft-owned AOT Models. Customer extensions live in a customer-owned AOT Model that references but never modifies Microsoft's objects.
The triage matrix in practice
The extensibility triage matrix from the source material is the working tool for the development migration:
Security: roles, duties, and privileges
Fusion's security model uses roles assigned to users, with function security (which pages and actions are accessible) and data security (which records are visible). VBS rules add attribute-based data security on top.
ALM: dev boxes, build pipelines, and the Power Platform admin center
[!WARNING] Fusion practitioners must plan for D365 ALM overhead from day one. The build and deployment pipeline is not optional and cannot be simplified away. Estimate at least two to three weeks to establish the ALM toolchain before the first X++ extension can be written and deployed.
What Fusion practitioners gain and lose
Knowledge check
Summary
Fusion's declarative SaaS extension model and D365's compiled X++ extension model are architecturally different in ways that affect every Fusion developer and functional consultant on the migration.