L4G, the dictionary and entry-point layering translated into X++ extensions and Chain of Command
How the Sage X3 development platform — the dictionary, screens, windows, objects, activity codes, SPE/SPV/SUB entry-point layering, and the Syracuse web-server customisation layer — maps to D365's extension-only model of packages, Chain of Command, event handlers, and Power Platform; and how to triage the entire X3 customisation estate before committing.
What you will be able to do
Describe the X3 dictionary, its objects, screens, windows, and activity codes, and map each to D365 AOT equivalents
Explain the SPE/SPV/SUB entry-point execution order and why it determines triage priority
Explain why D365 prohibits overlayering and describe Chain of Command, event handlers, and extension classes
Triage the full X3 customisation estate into keep, rewrite in X++, move to Power Platform, Dataverse table, ISV, or retire
Size the customisation rewrite workstream using intent recovery rather than code-volume counting
Introduction
Sage X3's customisation estate is built on a development platform that shares one deep assumption with D365 Finance & Operations: the application is metadata-driven, and both the data model and the behaviour attached to it are defined in a central repository.
The X3 development platform
The dictionary is the central metadata repository in Sage X3. It defines everything the application knows about its own structure: tables and their fields, data types, indexes, links between tables, screens, windows, actions, objects, entry points, and processing logic.
SPE, SPV and SUB: the entry-point layering model
At runtime, when an object action fires, X3 resolves entry points in SPE → SPV → SUB order. SPE code can intercept, modify, or suppress what SPV and SUB would do. SPV can override SUB. SUB provides the baseline.
Syracuse: the web-server customisation layer
Syracuse is the web application server that delivers X3's browser-based user experience. It renders screens, manages sessions, handles authentication, and exposes REST and SOAP endpoints. Syracuse customisation includes:
The D365 extension model
D365 Finance & Operations prohibits modification of standard metadata. All standard tables, classes, forms, enums, and data entities are sealed. The build system rejects any code that attempts to alter a standard object directly. This is not a deprecation path — it is a hard architectural boundary.
Triage of the X3 customisation estate
Recover business intent first. Do not read L4G code line by line looking for a translation. Ask: what does this customisation do for the business? What outcome does it produce? What would break if it were absent? Check whether D365 standard covers it.
Deployment and the service-update cadence
X3 deploys changes through patches — dictionary exports applied to target folders, validated by folder validation, and sequenced by revision numbers. A patch carries metadata changes (screens, fields, objects) and L4G code changes together.
Knowledge check
Summary
The X3 customisation estate does not convert to D365 — it is reinterpreted. The dictionary's metadata-driven objects map to AOT elements in Application Explorer. SPE entry-point scripts become Chain of Command extensions or event handlers in X++. Syracuse presentation customisation moves to Power Platform or retires.