AX 2012 and the impact on Design with the new Security Model

With the release of Microsoft Dynamics AX 2012, one of the great new things, at least by my own opinion, is the role based security model. To help understand the impact of what this brings with AX 2012, I think it's important to understand what existed before AX 2012.

With AX 2009 and even before that in 4.0, the security for AX was basically around security keys.


Security Keys in AX 2009

With this, there was then Security domains, in which could span all, or some companies within AX, and finally User groups, that tied permission, to security keys in AX.


User Groups in AX 2009

With this, we had a very granular approach to permissions for users, and honestly for a lot of implementation projects this was an after thoughts, or something that was done closer to go live. Before the security profiler tool, this was a huge pain at times.: Dynamics AX 2009 Security Profiler tool

Now we have a whole new approach to security, based on Roles. This is a huge improvement that brings a lot of new scope possibilities actually, like segregation of duty, rule based-date effective assignment of privileges, and so forth. Because of this fact, security has a larger impact on design time, for when implementing AX 2012 for a client.

The very first impact that this has, is around customization and gap scope that comes out of discovery phase of a project. Typically a project creates functional requirements documentation as well as functional design documentation. This is driven by functional consultants, and role based security should be looked at now from a functional level.

This is no longer mostly a technical issue, but a functional need. Understanding what you can do with the new Role based security, can impact a functional design, and possibly even the nature of a process.

Going back to our first impact then, and what focus needs to be around the functional requirements and design documentation. Sessions should exists at this level, that list at least what Roles, Process Cycles, Duties & Privileges might be affected, or even need to be created as part of the design process.



Further, if as part of the initial go live, segregation of duty will impact the customer that AX is being implemented for, then the new functionality that enables this needs to be looked at. This is where a company can setup, based on privileges, which are high, medium and low risk, when a user is granted such privileges.



This focus at the functional requirements and design level, will help when it comes to the actual technical design, setup, modeling and development efforts. Doing this, will enable the technical engineer or architect to correctly lay out a technical design that meets the requirements, that has security at the forefront of such designs.

This is very important, and this impacts reports, forms, services, tables, etc. etc. It is a good point to state, that security keys still exists in AX 2012, but only for backwards compatibility. These are no longer used to help define role based security instead: privileges roll up into duties. Duties then in turn roll up into process cycles. Finally process cycles role up into Roles.

Since this is the case, when someone is developing or modeling custom scope, and artifacts, the level in which security is implied lives within a new Security tree node, as part of the AOT.



This deserves further dives, specifically around code permissions, and other topics that need real attention, more than they have ever needed before. There is real value however, that comes from understanding the impact that the new Role based security has on AX. Having this understanding means, great ROI for customers, and that my friends is the bottom line we are all after.

Well that's all for now, check back soon as a whole lot more to come. Till next time!

"Visit the Dynamics AX Community Page today!"