Hi there!

In AX 2012, role based security provides an extensible framework for defining access to the Microsoft Dynamics AX application and data. It changes a little bit from what we know in ax 2009.

In AX 2009, administrators had to, literally, create their own user groups and manually assign users to those groups.  Also, in order give permission to a user group to execute a particular operation, the administrator had to identify objects, such as tables, fields, and menu items that were required for the operation, which was a pain in AX 2009 as identifying these elements was time consuming.

However, in AX 2012, security is role-based, and many security roles are predefined by the application to make the setup portion of it easy for us. Now, it is important to really comprehend this positive change as in role-based security, users are assigned to roles based on their responsibilities in the organization and their participation in business processes.  In fact, AX 2012 introduces duties, which are a group of privileges (See a short definition below). In addition, an administrator no longer has to identify application objects and grant access to those objects. Instead, the administrator grants access to the duties that users in a role perform and that's it.

In addition, in AX 2012 all permissions for all application objects have been grouped into task-based privileges and duties.  This means that an administrator only has grant access to the Maintain sales order duty, which includes all of the permissions that are required to view, create, modify, and delete sales orders.

Another interesting change has been the concept of reusable permissions.  I don’t know if you had the chance to work with multiple companies in AX 2009, but you couldn’t allow user groups could not span multiple companies. As a matter of fact, if the same functional role was required in two companies, an administrator had to create two user groups and so on and so forth. You know where I’m going with this, right?

In terms of record-level-security, this function is still available in AX 2012, but it will be removed in future versions. In ax 2012, the data security framework I used to help secure the data and take security privileges into account. For example, an administrator can grant View access to one subset of Purchase Orders and Edit access to another subset of Purchase Orders.

There are a few definitions about the AX 2012 security terminology I would like to share with you:



A security role represents a behavior pattern that a person in the organization can play. A security role includes one or more duties.


A duty is a responsibility to perform one or more tasks.  A duty includes one or more privileges.

Privileges specify the access that is required to perform a duty.  A privilege includes one or more permissions.

Permissions include the access level to one or more securable objects that are required to perform the function associated with an entry point.

For more information on AX 2012 security you can go to http://technet.microsoft.com/en-us/library/gg731787.aspx


Take Care!