Development and architecture

How IFS Foundation's PL/SQL-based Logical Unit architecture, custom fields, custom events, Developer Studio, and layered customisation translate into D365 X++, the AOT, the extension model (Chain of Command, event handlers, no overlayering), security architecture, ALM, and Power Platform.

What you will be able to do

• Map every IFS customisation surface to a D365 extension or Power Platform counterpart
• Explain D365's no-overlayering rule and why it differs from IFS's layered application model
• Design an ALM pipeline for D365 X++ using deployable packages and Azure DevOps
• Choose between X++ extension, Power Platform, and external service for each customisation category

Introduction

IFS Foundation's architecture is distinctive: every business object is a Logical Unit that bundles an Oracle database table, a PL/SQL API package (*_API), projection metadata for REST exposure, and Aurena UI binding in a single versioned runtime object.

IFS Foundation architecture: LUs, PL/SQL, and the customisation surfaces

The IFS Logical Unit (LU) is the atomic unit of the IFS architecture. Each LU represents a business entity (Customer, Sales Order, Work Order), and carries:

Custom fields, custom events, and custom objects

Custom Fields (the IFS CFP mechanism) add columns to existing LU tables. The column is registered in IFS metadata, exposed through the LU's projection, and can be added to Aurena screens. Migrating a custom field to D365 requires:

D365 X++ and the AOT: tables, classes, and forms

D365 X++ is a statically-typed, object-oriented language that compiles to .NET Common Intermediate Language (CIL), executed by the CLR. The AOT (Application Object Tree) is the metadata repository for all D365 artefacts: tables, data types, extended data types (EDTs), enumerations, classes, forms, data entities, security roles, and…

D365 extension model: CoC, event handlers, and the no-overlayering rule

The D365 extension model is enforced by the compiler: Microsoft's standard models are read-only. A developer cannot open a standard X++ class and add a method. Instead, extensions augment standard artefacts from a custom model.

ALM, deployable packages, and Power Platform

Models — the unit of source control; each custom model is a Visual Studio project referencing the standard application models Deployable package — the compiled, deployable artefact created from one or more models;

Custom objects and extension mapping bridge

IFS customisation surfaces have close D365 equivalents, but the target is not always F&O. The first design question is whether the custom object must participate synchronously in F&O transactions.

Knowledge check

Summary

IFS developers will find D365's extension model intellectually familiar: the principle of separating standard code from customer code is shared. The constraint in D365 is stricter — overlayering is compiler-enforced as impossible — but the benefit is real: Microsoft can update the standard code without breaking customer extensions.