Back to Blog

Moving to an 'Extensions Mindset'

Post by |

A major change in how developers need to approach customisations in Dynamics 365 for Finance and Operations is happening, this blog outlines the background to the change and the timescales for when developers need to move to an extensions mindset.

In Dynamics AX 2009 and 2012 the standard way of customising Microsoft source code and metadata (these will be referred to as elements for the rest of the post) was achieved through a technique called over layering. Dynamics AX was built on a layering system, where the Microsoft elements were part of the lowest layer of AX called the SYS layer. Built on top of this layer were layers for ISVs (Independent Software Vendor), VARs (Value Added Reseller), CUSs (Customer) and USRs (User) to add their own elements, and also overlay Microsoft elements.

For example if an ISV wanted to make a change to a Microsoft element in the SYS layer. AX would take a copy of the element they were wanting to change into their own ISV layer. The developer was able to freely make changes to the Microsoft source code in their copy, so they could change its behaviour and implement their own custom logic.

When the developer had finished making their changes, the AX compilation process flattened all the layers taking the version in the highest layer and compiling that as the active element for the application. Although this provided great flexibility to allow the developers the ability to implement their own custom changes, it came with a cost in that each change increased the complexity and duration of upgrades.

To explain this, imagine in the scenario above where an ISV had over layered Microsoft code and implemented their own logic with the Microsoft code. In the next release from Microsoft, Microsoft also updated that code with their own new logic. When the ISV upgraded to the latest Microsoft code they would have to manually work through these conflicts to decide if they should take the new Microsoft code? Should they merge it with their own code? If so, how should they merge it? Or should they remove their code and replace it with the new Microsoft code?

For each element an ISV had over layered, they would have to go through this same thought process and decide what approach they should take. The resultant changes would need to be implemented, and then tested to ensure no degradation in functionality. Alongside this, overlay customisations could have potentially also been made in higher layers by VARs, customers and users. For each layer the same merge process would need to be completed. Which could often mean that upgrades could become large complex projects.

The consequence of this often meant that the take up of new upgrades released by Microsoft was reduced due to the complexity and scale of the changes and required testing. The roll out of new Microsoft features, hotfixes and updates to customers was often slow.

With the new version of AX originally code named 'AX7', now known as Dynamics 365 for Finance and Operations came a new way for developers to add to Microsoft code called extensions. The word 'add' was key in the last sentence, with the release of extensions it meant that developers would need to change their mindset and think about adding to Microsoft code rather than changing or customizing the actual Microsoft logic.

Extensions unlike over layering don't provide the same flexibility to change Microsoft code behaviour to meet your own customisation needs. They allow you to be additive in nature and add code to complement the existing core Microsoft logic. No longer should developers be removing code and inserting inline code nested within the Microsoft code. Developers now need to think how they can implement their own business logic in pre- and post- events that surround the execution of the Microsoft code to achieve their needs.

The functionality and story around extensions is increasing with each Microsoft release. The image below provides a high level overview of the functionality that has been released for extensibility in the first ten platform update releases. It is likely that the extensibility features available to developers will continue to increase with future platform releases.

Platform 1

  • Extend EDTs
  • Hide menus through extensions
  • Extend a query

Platform 2

  • Extend a view
  • Enable code behind in extension forms

Platform 3

  • Extend labels
  • Add form parts to a form extensions
  • Change a form caption using a form extension
  • Change the label of a table field using a table extension
  • Customise application reports using extensions
  • Customise Help using extensions

Platform 6

  • Extend number sequence scope through extensions

Platform 7

  • Extend a group control
  • Extend the Country Region Codes property
  • Validate events on form data sources and form data source fields

Platform 8

  • Change the extended data type (EDT) on a table field using table extensions

Platform 9

  • Chain of command

Platform 10

  • More functionality is likely to be continued to be released

Developers in Dynamics 365 for Finance and Operations now have two techniques for making changes to Microsoft code, but not for long. Microsoft have released a road map of how they are planning to deprecate over layering as a development technique. This would leave extensions as the way that developers should be implementing their business logic now and in the future.

We have talked about how over layering increased the complexity, effort and duration of upgrade processes. Using extensions reduces this complexity because the customisations are adding to Microsoft code not changing the behaviour, therefore there will be no complex merging of conflicts in the code. They are compiled into separate assemblies to the Microsoft code, which allows Microsoft to update their assemblies without impacting the extension assemblies developed by ISVs.

As part of their road map Microsoft have announced how they are going to soft seal and hard seal the models. Soft seal means that models which have overlays will generate compiler warnings for these overlays. This warns developers that they need to look at removing these overlays as in the next release they will likely be hard sealed. Hard sealed means that models which contain overlays will generate compiler errors for these overlays. The model will not be able to be successfully built without removing these overlays.

Microsoft have already hard sealed a number of models including the Application Platform and Application Foundation. This has facilitated the monthly platform release cycle and given developers and customers an early indication how the hard sealing of models can increase the frequency of rolling out new functionality and hot fixes. In the platform update image displayed earlier in this post it can be seen that Microsoft have released monthly updates of new functionality and hot fixes, due to the hard sealing of models.

Microsoft are intending to hard seal all models by the spring 2018 application release, so developers have a definite timescale to move all overlays to extensions. Below is an image which details the planned road map for soft sealing and hard sealing Microsoft models.

Image taken from the article: Application extensibility plan

As you can see from the above image, the Application Suite Core models have been soft sealed in the Spring 2017 application release. The following release in Fall 2017 these models will be hard sealed. Also in the Fall 2017 application release the Application Suite model will be soft sealed, before they are hard sealed in the Spring 2018 release. The Application Suite is likely to be the model that has been predominantly over layered by ISVs and therefore has been likely left to last to give developers time to remove these overlays.

When the Application Suite is hard sealed in the Spring 2018 release, over layering will no longer be allowed and it will be extensions based customizations only. So as developers we need to start planning the move from overlays to extensions and learning key extension techniques.

Key points:

  • Overlays are planned to be deprecated by Spring 2018.
  • Extensions are the new way to make changes in Dynamics 365 for Finance and Operations.
  • Developing with extensions is a change in mindset for developers.
  • Changes need to be additive.

About the Author:


Chris Lowe is a Technical Architect for LexisNexis working on the Dynamics 365 for Finance and Operations version of the LexisOne ERP solution. He is based at the LexisNexis office in Leeds, UK, where he has been working on Dynamics 365 for Finance and Operations for approximately the last 2 years. Prior to this he was working on the Dynamics AX 2012 version of LexisOne. Before his move to Dynamics AX related technologies he worked on .Net browser based applications in both the legal and banking industries. He has 20 years’ experience working in IT software development.

| See all our contributors
Back to Blog