The “Just Do It” Approach for AX Security Access – Not So Good for Everyone

How often have you felt like this when you get an email to work on an issue but there is little to no explanation as to why or how to do it? Unfortunately, it happens all the time as we all can forget to be specific when needed. This is especially true if you are dealing with any security requests in your organization, such as user access requests. When the security administrator receives a request for AX 2012 user-role access, it could conflict with the AX 2012 security model best practices, segregation of duties, and may not even be required as part of the job tasks of the requester/user.

Let’s look at one such request:

“The user needs a role to access this field (the user would include a screenshot of the field here). This role needs to only edit this field on this sales order form. This role should not be able to edit anything else in the sales order, please grant this access, thank you.”

To accomplish this request, here is a list of tasks that will be required:

1. Create an AOT project
2. Locate the correct menu item or table and field in the Application Object Tree (AOT)
3. Create a new role or assign the specified role to the project
4. Add the table to the role permissions and set the table access level to Update
5. Add the required field to the table and set the access to Update
6. Add the rest of the table fields to the table and set the access for those fields to Read
7. Test the user access with the single role
8. Test the user access with the user’s security role “stack”

In the mind of the responding administrator, this will take a long time to accomplish, and is not ideal, but you may just do it because that is what you were instructed to do.

Advice to the Requester/User

Try to take a step back and understand that what you are asking may not provide enough information for the person who will do the work. It does not explain much, other than a request that a specific field should be editable. This is where things can get confusing between you and your admin, and you can turn what you thought was a simple request into a long and complicated ordeal. Dealing with security can be quite a headache, especially if you are not familiar with AX security and the work that goes into making customizations to user specifications. This is due to the architecture and complexity of AX 2012 security, so you may find that the resulting access granted is not what you expected, or may not be able to be accomplished at all.

Your security administrator may have to go field by field, revoking access to every single field on the form. At this point you should also ask yourself, if this is the case, do I want to create all this work just for edit rights to a single field?

Advice to the Security Administrator

A good approach would be to stop and ask: “If users are requesting access to a specific field, is it possible that this change could provide access to other fields or forms?” Because of the way AX Security is built, a change such as this will require you to upgrade the current Read access of the Sales Order form to Update or Delete rights, unlocking the entire sales order form for creation, editing, and other functions. This is because if the table is left at Read access, a user would not have the ability to edit fields, and you would receive an insufficient access error while working on the security development.

This type of request should be run through the business, to determine if a potential segregation of duty conflict exists, or if this request is operationally required.  Perhaps there is no real business harm or segregation of duty conflict, then assigning a role or limiting some key functions on the form will be a better approach. Here are some reasons why you should challenge these requests:

• If the person who designed this security leaves the company or changes billet, you are going to lose visibility and more importantly, the context in which the security change was made.
• AX Security should be kept as simple as possible, within the constraints of roles, duties, and privileges.
• If you agree to this level of customization, the business may begin to expect this work for future access requests.
• Do we really want to apply permission overrides, form controls, and field level table access, when the actual requirement could be much simpler?

The best way to go about requesting access is to be specific, provide as much detail as possible, understand the justification of business, and most importantly try to minimize the effort for customizing security.

By Dennis Korol, Functional Consultant for Arbela Technologies

The post The “Just Do It” Approach for AX Security Access – Not So Good for Everyone appeared first on Arbela Tech.