Dynamics 365 Finance & Operations – Understanding Elements, Models & Packages


Here is a quick explanation of Models and how they work in Dynamics 365 Finance & Operations. To assist those that are coming from a D365 CE background, I have tried to compare Elements, Models and Packages to Solutions in D365 CE.

What is an Element, Model and a Package?

Elements are components like Tables, Forms, Metadata, Source Code. Models are a group of Elements that make up a core functionality of the Platform (Sales & Marketing, HR, Accounts Payable, Accounts Receivables). Models can also exist at different customisation layers. More on this later. Packages are Models that can be distributed as an archive file to other platforms like Production for deployment.

Models are the most crucial component to understand. The Microsoft documentation page has a really good conceptual summary of a Model:

A model is a group of elements, such as metadata and source files, that typically constitute a distributable software solution and includes customizations of an existing solution. A model is a design-time concept, for example, a warehouse management model or a project accounting model. A model always belongs to a package. A package is a deployment and compilation unit of one or more models. It includes model metadata, binaries, and other associated resources. One or more packages can be packaged into a deployable package, which is the vehicle used for deployment on runtime environments.


Understanding that Elements exist in a Model, and a Model exists within a Package and Packages can be deployed to other environments, the whole concept of Models seems very similar to Dynamics 365 CE Solutions.

Element = Component in D365 CE (Entity, Form, Dashboards)

Model = Collection of Components inside a Solution.

Package = Solution.

How do Layers work in a Model?

Now that the terms Element, Models and Packages have been clarified. Let’s understand the basics surrounding Layers.

The Microsoft Dynamics platform is almost completely customizable. This means that the platform itself can be dangerously modified to the point where it no longer functions as intended.

To protect against over-customisation or incorrect customisation of key components, Microsoft introduced the concept of Layers.

In Dynamics 365 Finance and Operations the following Layers exist:

At the very bottom of these Layers is the SYS Layer. The SYS Layer contains Elements that Microsoft owns. You cannot modify this layer.

Above the SYS Layer are several other Layers such as ISV (Independent Software Vendor).

Above the ISV Layer is the CUS and USR Layers.

An end-user is always able to interact with everything at the highest Layer. This means that the USR Layer supersedes all other Layers.

Take the following example on the CustTable (Customer Table).

By default you may see the following form out-the-box:

After the installation of an ISV package that removes fields from the form, you may be left with:

Now if you were to add a new Model that contains customisations on the USR Layer and you removed a set of fields in this Layer, you may end up with:

Finally, assuming that you removed the ISV Layer of customisations. You would still be left with the following customisations:

The reason for this is that Dynamics 365 Finance and Operations always uses the highest layer. The USR Layer customisations would always supersede all other Layers.

It’s common practice to use the CUS or the USR Layer when you are customising the platform for a single organisation, and where you do not intend to release your package as an ISV solution.

Reference Packages

Reference packages are essentially containers of objects. These packages contain base or core tables such as the CustTable. This means that if you wanted to create an extension on the CustTable, you would have to add the correct package that contains the CustTable. How do you know which package an object belongs to? If you search the AOT, you will be presented with the package in square braces.

In the above example – CustTable belongs to ApplicationSuite reference package. So when you create your Model, you will have to add the ApplicationSuite to as a Reference Model.

When you select a reference package, you will be presented with the following:

Adding or updating Models

When your Model does not contain references to other Models that contain assemblies, you will run into compilation errors. For example, if you are generating custom number sequences and you have declared the following line of code in a class:


You might find that during the build cycle, you get a compile error:

The name NumberSeq does not denote a class, a table or an extended data type.

To fix this error you need to add the correct Packages that contain the right assemblies. In the example above, I updated my Model to include a reference to the ApplicationFoundation Package.

There is no real guidance on what to include in your Model. The best practice is to start with the very minimum and then add packages when required.

Leave a comment