Layers segregate modifications (or the creation) of an application object's elements (for example, a field on a table or a control on a form). This allows Microsoft partners/ISVs and the customer to write a new functionality or change an existing functionality in a specific layer without directly modifying the standard software or the software supplied by the partner or ISV.

The following layers are available from the highest layer down:

This information is taken from http://msdn.microsoft.com/en-us/library/aa851164.aspx.

Each layer has a patch layer, where SYP is the patch layer for SYS, and so on. The patch layer is used to ship hotfixes and service packs. A range of tools can be used to compare and merge code into a higher layer (that is, USR), where it has been changed by the patch.

The current layer is set in the AX configuration utility, and to use any layer other than the USR layer, you need an access code, which Microsoft provides as part of your license.

When a change is made to individual elements (methods, fields, form controls, and so on), it is copied to the current layer. This copy then hides the element in lower layers. The compiler does this by looking down at the elements from the highest layer down—as if it were looking through the panes of a glass—as shown in the following image (which is taken from Microsoft TechNet):

The exception to this is if we modify an object that is already in a higher layer. In this case, the change is done in the higher layer—if there is any change in the current layer, it is not used. This is by design; if the change was made in the lower layer, it would not be used, as it would be masked by the higher layer change.

This means that your changes are protected, allowing you to merge the changes as required.

Commonly, your partner will develop features or customize AX in the VAR layer, and the end user (the customer) in either the CUS or the USR layer.

On rare occasions, the customer may use both CUS and USR. One example would be a global organization that has systems in several countries and employs an internal development team. In this case, the internal development team will develop the core system in the CUS layer, leaving the country to develop its own specific requirements in the USR layer.

Prior to AX 2012, the elements were not shredded to a sufficient level. In other words, forms were treated as one element and therefore copied in their entirety to your layer, should you simply add a field to a grid. This posed a problem for Microsoft because it limited the amount of add-on solutions that could coexist in a system without a developer merging the code.

This shredding of elements, into individual controls on a form for instance, exposed another problem for ISVs developing add-ons on AX.

An ISV would write their add-on in a specific layer: for example, SLN or ISV (in the previous versions, it would be the BUS layer). They would deliver their solution as an entire layer (which used to be a file ending in AOD) along with labels.

This, therefore, limited the number of ISV solutions you could use within your implementation without greatly increasing the complexity of implementing them.

The answer to this issue came in the form of models.

Every element in a layer belongs to one model; if a layer does not have a model, the system will create a default model for it when a modification is made; for instance, the USR model. These are not normally used and, in my opinion, should never be used, as we cannot be sure whether this was intended.

A model exists in a specific layer, and elements in a layer can only belong to one model; this is by design and should not be thought of as a limitation. Thus, a model is a collection of elements in a specific layer.

If you import an add-on as a model, it will be imported into its original layer. The only thing you have to do is to synchronize, compile the application, and regenerate the CIL. This model can also be removed; again, all you need to do is synchronize, compile the application, and regenerate CIL.

You can then, in your layer and model, make changes to the add-on for your specific requirements; and when the ISV releases an upgrade, you simply have to import the model and use AX's tools to highlight the changes that may conflict with yours.

Models have many benefits, and I suspect more than what were initially intended when designed:

For ISVs, models create the following abilities:

For partners, the benefits of models are the following:

There are advantages for customers too, which are as follows:

In our experience, partner and customer layers typically have the following models.

Typical partner (VAR) models are as follows:

Here are the typical customer (CUS or USR) models:

The reason a label file is in its own model is that the label file is not shredded into elements, and therefore, all labels in a label file exist in one model. Each party would normally maintain one label file, which has a three-letter name, and is therefore limited.