Dynamics AX Development Standards and Best Practices

by | Updated January 3, 2018 | Development, Dynamics AX

Standards and best practices are a great way to bring a development team together to have uniform code and features across Dynamics AX or any software project. Especially with the over-layering capabilities in AX having a set of best practices can be crucial to being successful in a project. Here are some of the Dynamics AX standards and best practices we recommend using while doing customizations and development.

Establish a source control system

Having a source control system is a very important part to managing code. Not only does it give you security while making changes, but it gives you historical data on changes made. I have used Microsoft TFS (Team Foundation Server) extensively and really like both its issue logging system and Version Control system. I’ve written a couple other blogs around Helpful TFS Queries and TFS Code Repository .

If you are going to use a source control system, make sure you get in the habit of pulling down code or “syncing”. This will keep you up-to-date and keep from conflicts occurring.

Have a task tracking system

Whether it is bugs, features, or changes life is easier if you have a way to track it. There are a lot of great tools out there for tracking this information. I have, again, mainly used TFS. It gives a large number of fields and is customizable. Emails get lost and it is hard to keep track of things that are priority. So having a central system to track tasks will help on any project.

Create a code commenting standard

When doing customizations in AX it is important to comment your code so that when it comes to for upgrades and/or hot fixes the code merge process becomes much simpler.

First, type of comment is the inline comment. Here we are adding code to an existing method. Here you want to wrap your changes with comments.



This is just one standard, your organization might prefer a different comment structure.

The second type of comment is the XML header comments. It is recommended that you generate these before any public method, but it is also advisable to add it to any method that you create. Not only does it give a good synopsis of what the method does, but it can also help future developers understand when it was created and for what feature/change. The system will generate this for you by simply going to the line above the header (public int …) and typing “///” (without the quotes). This will generate something like this:

It is wise to fill this out and put in the <Feature/Bug number> <Description> <Date> <Initials> into the remarks section.

Use the tools available

Microsoft provided some tools to help validate best practices and standards:

Compiler BPs

The most common one is checking for Best Practice violations or “BPs” when compiling.

To do this simply go to (from the Development workspace): Tools > Options > Development.

Click the Compiler button


Set Diagnostics level to “Level 4”


Doing this will make it so that when you compile any object the BP failures show up in the message log.


Form Style Checker

Another tool is the Form Style checker. The form style checker will verify a form’s layout to see if matches that of predesigned form templates. This tool is very helpful when a new form is needed in AX. To read more on Form Style Checker, you can read about it in a blog article here.

Code reviews

Having others review your code is always a good idea. Having others review code changes gives different perspectives. This becomes even more beneficial for larger projects. When you are in the depths of coding it is easy to miss things. Having a second pair of eyes can find mistakes or code performance issues.

Doing a code review should be practical and to the point. Point out needed/suggested changes without pointing fingers or blaming. It can be hard at first to have someone review your code as you can feel like you are being judged. Instead, treat it as a chance to learn and grow as a developer.


In general, we (Stoneridge Software) recommend doing development in one layer. CUS and VAR are the 2 more common layers. We do not recommend doing development in the USR layer. In addition, for the most part, it is wise to only have modifications in one model as well. This makes upgrades much easier to work on.

Keep shipped code clean

While doing modifications, try to put as little code into the base objects as possible. Create new helper methods and classes to do any heavy lifting where possible. This makes it so that the base objects will only have a few lines added/modified. Of course, following the commenting guidelines mentioned above.

Use Labels

Labels are a way to do string replacement in AX. They are very helpful if your company is multi-lingual. In general, if a label exists in the SYS layer it is safe and recommended to use. I would shy away from using labels from ISVs though as they may be a bit more unstable. If unsure, it is always safer to create your own label in your own label file.

Coding standards

Every organization with a development team should have a set of coding standards.

Such as…

These are just a few different things to keep in mind while doing Development in AX. There are plenty others as well. If you would like, here is the whitepaper from Microsoft on this topic: Microsoft Dynamics AX 2012 Best Practices for Developing Customizations Whitepaper.



Related Posts


Submit a Comment

Your email address will not be published. Required fields are marked *

Upcoming Events


02jun2:00 pm2:30 pmBusiness Intelligence for Batch Manufacturers

16jun10:00 am10:30 amHow AP automation can speed up month-end close in D365 Finance

17jun11:00 am12:00 pmConfab Live with Stoneridge – Real Time Marketing Strategies for Success

23jun10:00 am10:30 amThe Modern Manufacturer: Cost Accounting in D365

30jun10:00 am10:30 amAP Automation Checklist for a 2022 Rebound

30jun2:00 pm2:30 pmAchieving Success: How Technology Is Helping Nonprofits Thrive


01jul11:00 am12:00 pmConfab Live with Stoneridge – Dataverse Virtual Entities

14jul12:00 pm12:30 pmBeyond Reporting - What Business Intelligence Can Do For Your Agribusiness

15jul11:00 am12:00 pmConfab Live with Stoneridge – Integration Strategies for End User Success

21jul10:00 am10:30 amThe Modern Manufacturer: Manufacturing Software in the Real World

21jul12:00 pm1:00 pmIs it Worth it to Upgrade to Dynamics 365 Finance and Supply Chain Management? - Everything AX Users Need to Consider

About Stoneridge
Stoneridge Software is a unique Microsoft Gold Partner, with emphasis on partner. With specialties in Microsoft Dynamics 365, Microsoft Dynamics AX, Microsoft Dynamics NAV, Microsoft Dynamics GP and Microsoft Dynamics CRM, we focus on attracting the most knowledgeable experts in the field to our team, and prioritize delivering stellar solutions with maximum impact for your business. At Stoneridge, we are deeply committed to your results. Each engagement is met with a dedicated team, ready to provide thorough, tailored, and expert service. Based in Minnesota, we intentionally “step into your shoes,” wherever you are. We focus on what you care about, and develop trusting, long-term relationships with our clients.

Subscribe To Our Blog

Sign up to get periodic updates on the latest posts.

Thank you for subscribing!