Segregation of Duties: Dynamics AX meets the financial auditor (part 2)

Setup and validation of Segregation of Duties rules in AX

Prior to the setup of the Segregation of Duties rules in AX itself they should be determined by the organization (create an SoD matrix). Next step is to determine which Duties contain access to the functionality that must be checked when given access to. In this step the standard Security Development Tool of AX can be used. When all this has been done the actual setup of the Segregation of Duties rules can be undertaken.

Setting up all Segregation of Duties rules can be a time consuming, depending on the amount of duties that need to generate a conflict. This can especially be the case when Duties have been copied  to be used in various roles, but the prime entries are still present in this Duty (for instance sales order related access is still present in the copied duty whereas simultaneous access to purchase and sales information must be prevented). When a rule is setup it might look like below (this is a complete fictional example). The fields First duty and Second duty are of course the most important fields and for that reason these fields are mandatory. All other fields are more or less of an informational level.

We advice to add some fields to this form in order to make setup easier and to be able to check if proper duties have been used for the setup. For that reason it is very useful to add the AOT name tot he form to both duties; this can be done by personalizing this form.

Once all setup has been done it is time to use rules for what they are intended for, namely to validate if users have received too much access to functionality of AX. However this validation can also be used to verify if a role grants in itself  too much access to AX. Validation can and is performed at various moments.

With the button on above form the validation can be performed. In this way a check is performed on the existing roles if they are in conflict with the rules setup. Be aware that all rules must be executed one by one (!) and that roles present in AX are validated, so also roles that are not used or will not be used (because new roles are created that must be used to assign to users). In case validation errors are shown appropiate action can be undertaken. i.e. change roles in order to resolve to conflicts.

When a user gets a new (additional) role assigned the validation of segregation rules is performed automatically. In case conflicts are present a message is shown indicating what rule is violated.

Apart from this automatic validation there is also an option present in order to establish a periodic validation. This can help to ensure that no violations of the Segregation of Duties creep in without being noticed and evaluated.

Go to System administration > Setup > Security > Segregation of duties > Verify compliance of user-role assignments

  1. The validation can be executed as a batch-process (1)
  2. Use button “OK” to execute the validation (2)


When the validation is completed AX will display an Infolog with all validation errors showing below information per conflict:

  • User id;
  • SoD validation rule name;
  • Role 1 in conflict;
  • Duty in conflict within role 1;
  • Role 2 in conflict;
  • Duty in conflict within role 2.


An example of such a message would like shown below.

When conflicts arise these have to be resolved. The person responsible fort he Segregation of Duties should be informed and he/she should take appropiate action like assigning user(s) to other roles, reassigning roles to users, change configuration of user roles or SoD rules or accept the violation of the conflict. We will now have a look at how conflicts can be resolved.

Resolve Segregation of Duties conflicts in AX

When a user gets an additional role assigned and there is a Segregation of Duties conflict a message will be displayed.

After pressing Yes AX will display an Infolog with details as well as the form “Resolve segregation of duties conflicts”:

Find all SoD conflicts in AX

All conflicts identified by AX are listed in the form “Segregation of duties conflicts” (path: System administration > Setup > Security > Segregation of duties > Segregation of duties conflicts):

Note that all conflicts that occurred remain in AX and SoD rules related to conflicts cannot be deleted from AX. This gives an auditor an overview of all conflicts that have appeared in the past. However actions undertaken due to a conflict have to be retrieved from other parts of AX.

The field resolution (not listed in the screen print above) contains information regarding the status of the conflict.

Status can be:

  • None: conflict to be resolved (buttons Deny assignment and Allow assignment are available)
  • Override: conflict resolved (buttons Deny assignment and Allow assignment are not available).


Find unresolved SoD conflicts in AX

To find only unresolved SoD conflicts follow the path System administration > Setup > Security > Segregation of duties > Segregation of duties unresolved conflicts:

This resembles the form where all conflicts are shown. Only records with field resolution populated with “None” are shown. In this form a filter can be applied to find the conflict on hand, usually a filter is applied on UserId, like shown in the example above.

Allow SoD conflict

Based on the actual Segration of Duties policy it can be decided that a conflict can be allowed. It might seem strange to allow a conflict, but bear in mind that it can occurr that in some cases some staff members must be allowed access rights that they normally would not be granted. In these cases an exception can be made by allowing the conflict.

In order to do so, select the record containing the conflict and click the button “Allow assignment” (1).

When the button “Allow assignment” is activated AX will display a dialog where a reason for override can be entered.


It would be helpful to populate this field with a note that make sense. Some suggestions might be:

  • Direct based on the SoD policy of the organization (known conflict)

Date of approval

“Known conflict” + communicated to person responsible for SoD policy

  • Based on approval by person responsible (unknown conflict)

Date of approval

Name of person who approved the conflict

Additional text as determined by the approver

Important! After assignment is allowed one must return to the user form and assign oncemore the security roles that were not allowed initially. The system will now allow the role assignment.

Note: Once a SoD conflict has been allowed for a user, there will be no future conflicts displayed for this user and SoD rule combination. So in case a new conflict must be shown tables in the AOT have to be edited!

Deny SoD conflict

On the same form where SoD conflicts are allowed they can also be denied, so follow the path System administration > Setup > Security > Segregation of duties > Segregation of duties unresolved conflicts.

In case a conflict is not allowed, select the record with conflict and click the button “Deny assignment” (1).

The role with validation errors is not assigned to the user. However, if you were assigning two roles with a conflict in between these roles, one of the two was properly assigned while the other not. In case the SoD validation conflict is not approved, you must ensure that the correct role from the conflicting pair is assigned to the user. This may require unlinking the assigned role and linking the other role to the user instead. In case you were assigning one role in which a SoD conflict exists this role is not assigned and can’t be assigned by trying again (same SoD conflict will be reported.

Make sure that roles  that are known to contain a SoD conflict are listed in a SoD Matrix and can be assigned to users.

Leave a Comment!

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