This post describes how to develop, implement, and deploy an AX 2012 solution within the Enterprise Sure Step project type. This document will walk through a few scenarios of different approaches based on how
AX 2012 is to be implemented in the Enterprise. The basis for any Enterprise AX 2012 implementation is a core build which has all common customization mplemented. There may be some deviations to these customization required in rder to implement the core build to a specific site or sites. A site may be a ingle or group of facilities, regions, and legal entities. It will walk through different scenarios which will include the different approaches and how to implement the customization required for each implementation.

This document focuses on the code development and deployment and does not get into the complexities of data management/sharing across multi-instance Enterprise implementation scenarios. It also does not go into code management with the use of TFS even though TFS should be a requirement of any Enterprise implementation.

Core Build/Global Template

An Enterprise AX 2012 implementation involves a core set of functionality that is common amongst the entire implementation. This implementation can span from across site and across the globe.

When designing this type of implementation it is important to first determine which GAPs need to be filled as part of this common set of requirements. These GAPs should than become part of the Core Build/Global Template for the entire implementation.

In most cases the Core Build will be developed as its own Model in the VAR layer. In addition any Core ISV solutions will be merged using this Model and Layer.

Site Build

Depending on the implementation there may also be some requirements/GAPs that are only required at particular site and may become part of the Site Build. A site may be a particular locations, facilities, and/or regions.

In most cases the Site Build will be developed as its own Model in the CUS layer. In addition any Site ISV solutions will be merged using this Model and Layer. In addition any merging between the Core Build and the Site Build will take place in this Model and Layer as well.

General guidelines

In all Enterprise implementation scenarios there are some considerations that need to be taken into account when designing the customization required. The different scenarios below will walk through the specific details but regardless of the scenario the follow guidelines should be followed.

  • Appropriate design patterns should be followed in order to enable/disable functionality
    • Configuration keys
      • Customizations that are of a large scale and/or can be grouped together without impacting other customization and/or functional should be assigned new Configurations.
      • Smaller customizations should make use of the appropriate configuration keys that come as part of the standard code base.
    • Parameters
      • Where ever possible all setting should make use of parameters.
      • This should even be taken a step further with the use of parameters to enable/disable customization.
      • Parameters should be considered to be based on all nodes of the Organizational hierarchy including but not limited to System Parameters, Legal Entity Parameters in addition to the Module specific parameters.
    • Security
      • The role based security model should be design and implemented on all customizations. This may include new Roles, Duties, Privileges, and process cycles in addition to additions/modifications to the standard security objects.


Scenario 1 – Single instance

In a single instance scenario all customization whether required by all sites or just one site is contained in the Core Build. With this scenario the customizations must take full advantage of the appropriate Parameters and Security settings in order to enable/disable the appropriate functionality required by each site in the instance.

An example of some of the functionality that may require disabling/enabling is region specific features. Since there is only one instance the region specific features must be enabled for all the regions on the instance. In order to enabled/disable specific features the use of Parameters and Security is required. This needs to be taken into consideration when designing the Customization during the Design phase.

Scenario 2 – Multi-instances

This scenario is very similar to the first scenario. This scenario makes use of a single Core Build. This scenario differs in the fact that in most cases the instance are separate do to geographical distribute and/or region specific laws and regulations.

In this scenario Configuration can be enabled/disabled in order to enable/disabled region specific functionality. This is true not only for Standard features but also should be taken into consideration when designing the core build. For example if there is a feature that is required in one region which has its own instance but needs to be disabled in order regions/instances. In this example if the customization is designed correctly the configuration can be setup to support this requirement.

Keep in mind that just like the first scenario there still may be sites that are on the same instance but require slightly different functionality/customization. In order to support this the customizations must be designed with the appropriate Parameter and security settings in addition to the configuration settings as described above.

Scenario 3 – Multi-instances with instance customizations

This scenario builds on both the first and second scenario. All the requirements and considerations that were taken into account in those scenarios apply with this one. To build on the first two scenarios this scenario has the added complexity of certain sites/instances having a more unique set of requirements that causes them to need a Site Build. There may be a Site Build for just one of the instance or each instance may have its own Site Build on top of the Core Build.

This can be as simple as only one site/instance which has its own set of unique requirements or as complex as each site/instance having a unique set of requirements that build on the Core Build. The Core Build is still required in this scenario and should contain a set of common customization that all sites/instances require.

In addition to the architecture and design considerations required by the first two scenarios this scenario requires a merge process between the Core Build and the Site Build. This is not as important during design but will become important during deployment, operations (including support), and upgrade.


In conclusion, this post went through the general concepts, terms, and scenarios around Enterprise Model Development and Deployment. Enterprise Model Development and Deployment is one of the more
advanced concepts in the Sure Step Methodology and Dynamics AX ERP implementations.

It is important to note that there is no hard rule for which scenario to use. The scenarios above describe the different circumstances for using a particular strategy/scenario. In order to determine which scenario is appropriate for a particular situation, all the information around that situation needs to be taken into account and the Technical and Functional Architect should work with the Solution Architect in order to put together the solution that fits the development and deployment needs in order to provide the best solution for the Dynamics AX implementation.


For information related to deploying application metadata across Microsoft Dynamics AX environments (testing, staging and production), see
Deploying Customizations across Microsoft Dynamics AX 2012 Environments (White paper).