In the previous parts the present way of handling Segregation of Duties in AX was covered. In this final part some improvements or if you prefer some open topics will be commented on.
When looking at the form where Segregation of duties rules are setup and maintained and one thinks of the importance of such rules it is a pity that these rules don’t have versioning or a date of when it became active or something similar. In other AX functionality in many cases a rule or version must be activated but for Segregation of duties rules none of these things are present. I hope that in future versions of AX (Dynamics 365 for Operations) this will change and some thought would be put in versioning (and store the old versions of a rule) .
Maybe Microsoft wanted to add this functionality already because when looking in the AOT one can notice that there are two date fields that could be used for versioning. These fields are not standard shown on the form of the Segregation of duties rules, but they are part of the table anyway. So maybe in the future there will be functionality added These fields are shown in the frame below.
As mentioned earlier when conflicts are resolved the resolution of the conflict is stored for future use. This can be both wanted or unwanted depending on how you look at it.
It is wanted because it shows that the Segregation of Duties in in place and working. It can be unwanted when a conflict is allowed, to resolve an issue for which temporarily more access rights where necessary. However this resolution is kept and can’t be deleted from AX using one of the forms. When the role is assigned again no conflict will be shown! To avoid this it can be useful to clean the table from these resolutions using the AOT (or an X++ or SQL script).
As an AX environment is a dynamic environment changes to this environment will occurr on a regular basis, will it be an upgrade by Microsoft, installing an add-on or changes created by the organization itself or its implementation partner. When additional functionality is added, or existing functionality is changed, being the introduction of new buttons, new duties or new privileges or changing existing ones, the Segregation of Duties must be evaluated to determine if changes are necessary in the setup of the rules (are new rules necessary, can we dispose of rules, must we change existing rules).
To keep it short, once you start using Segregation of Duties in AX it must be maintained and be a part of a change procedure of an organization.
When looking at the standard AX roles in regard to Segregation of Duties it becomes clear that Microsoft created AX and the AX standard roles that support business processes, but not always had a keen eye for Segregation of Duties. As an example I would point out that creating negative purchase (RMA-orders) and creating normal purchase orders are processes that you would normally split, because inbound and outbound inventory tranactions shouldn’t be handled by one role. In the standard roles these processes are not separated. Also in the security elements this is not or not reflected. These anomalies will be encountered when a Segregation of Duties policy must be setup in AX.
So when a Segregation of Duties must be implemented it might well be, depending on the goals to achieve, that security elements must be added (privileges, duties, roles) in order to be able to ensure that it will work.
As one can understand is the above a result of coping with Segregation of Duties issues at various customers, working in various branches that have to deal with their own risks. It is also observed that this important issue is not always covered during the initial setup of AX at a customer. However it is an issue that should be addressed during an implementation or upgrade of AX.
When struggling with issues regarding Segregation of Duties and when help is needed give us a call.
Kaya Consulting has several consultants available who can assist with the setup of a Segregation of Duties policy (the SoD Matrix), implementing it in Dynamics AX (consisting of reviewing the existing security roles, creating new security roles and new security elements, setup of the Segregation of duties rules in AX) and documenting it, so the financial auditor gets a clear insight of what is going on in an organization for a Segregation of Duties point of view and IT-support staff knows how the Segregation of Duties can be maintained.