A role is a collection of duties and privileges. The role is what we associate with a user, which can be done automatically based on the employee's information, such as their position in the company. The security roles should be thought of in terms of the personas that first appeared with Dynamics AX 2012. The change is intended to move the thinking away from creating groups of functionality to design the roles based on how the organization is structured. For example, a Sales manager would be in a Sales manager role, which will have duties assigned. The duties have privileges, which in turn give access to the sales manager in order to perform that role.

In our case, we could consider that they have three roles: vehicle management supervisor, vehicle service supervisor, and vehicle service entry clerk. When defining the roles, we do so by defining the duties that each role will have. The naming convention is similar to other objects, and suffixed with the type of role. These types include Supervisor, Manager, Clerk, or others should these not fit the required role; for example, ConWHSVehicleManager would have the Maintain duties for vehicle master data.

We can add privileges directly to a role, but we should be strict and only add duties directly to a role. This assists in maintenance, and, additionally, it is a best practice check to have all privileges in one or more duties, and all duties must be in one or more roles.

We can also add roles as a sub-role. This may help in rare cases, but, again, try to avoid this. It makes maintenance a little more restrictive for the security manager. They may want to grant or restrict access to the sub-role without changing the rights of the parent role.