Importance of Security Process Cycles in AX2012 Security

I am sure that majority of us ignored this best practice and continued to implement AX2012 security without putting objects into process cycles. Today I learned the lesson of paying price for ignoring this best practice where Microsoft recommends to put each security duty, under minimum one Process Cycle. I would like to share problem, the experience I went through and a quick solution; quick for us lazy people like me (who don’t want to get through hassle of managing Process Cycle).

I can understand that why majority of us have been ignoring the process cycle; It was because process cycles seemed very useless. If we see practically we cannot assign Process Cycles anywhere in AX. Such as you cannot assign process cycles to users for controlling security. You cannot use process cycles to manage workflow approvals etc.

One of my clients gave me shout, as she was unable to ‘Remove security Privileges from a security Role’. As an initial repose to her call I told her to open security development tool (SDT) and duplicate security duty and finally apply changes on duplicated security duty. But she came back with

“it’s hard to do in SDT and SDT is suggesting me to modify the objects (duplicate and apply changes) I want to remove security privilege from a security role.”

I went back to her with suggestion of using security role form and remove the security privilege she is looking to remove. As demonstrated following (I suggested her).

• Open security roles (standard AX Form)
• Click the role, you want to remove privilege from 
• select security duty and click on 'Edit Duty'

• Now select the privilege that you want to remove from security role and click the delete button.  

If you are using standard AX2012 with no changes in it, this process will work for you because Microsoft has shipped objects after testing. But my case was different as I am sure majority of implementations go with customized security roles. My client had been using SDT to prepare new security roles (duties, privileges). As they tried to perform the procedure (shown in above images) on customized security roles, they were unable to delete security privilege. I was scratching my head with thoughts, as if my user has done some blunder while they were preparing security objects using SDT. This made me to open debugger and see what is happening.

Debugging showed me that Microsoft developed forms don’t allow you to manage(delete) security objects if those are not defined under a Process Cycle. If security duties are part of process cycles, you can modify those using standard AX without going into AOT, otherwise interface will disable delete button.

Solution was very simple after debugging showed what is the problem. Simply drag all your customized security duties into a new or existing process cycle. This will allow to remove a privilege from a security role.

But it’s not that simple practically. Because your users may create new security objects anytime and you cannot tell them to drag security duties into process cycle, every time. Most likely they would hate it. When Security duties can be created using SDT without going into AOT, then why cannot AX manage to drag security duties under a process cycle automatically. Why AX is wasting users’ time to drag security duties under a process cycle, manually. It should save user time. Secondly if you have hundreds of security duties, you would not want to waste your time, by adding those to process cycles.

I thought about this and I was looking for nothing more expect two things

1)     Save my users’ time, by presenting them an easy way to drag objects into security process cycle.

2)    Automation of this process, so they don’t need to call me again, if they forget to add a duty under process cycle. Because if they will forget to add security duty under process cycle, they would not able to manage it using user interface and I don’t want my users to think about AOT.

My mind suggested me to code and provide them an automated experience. Spent few minute to write a script that makes sure that all customized duties are part of a process cycle. Every time user opens the form to manage security objects, it checks if any security duty is not part of process cycle, it adds itself. Also it makes sure that there is a process cycle, independent of existing process cycles, so that all your customized security goes into your own process cycle. Nobody would like to customize existing process cycles. Less the customizations, better it is. I have uploaded the script, anyone my download to use it.

After I added this script in AX, all went perfect and user was able to manage security object using standard AX forms (without going into AOT). I hope I will not get any more phone calls from them on this subject. :)

Please share your experience, if you have got a better idea to manage this using automation.