Security how-to: Only a finance user is allowed to change the on-hold status of vendors and customers
This post is a new blog in the series about “Security how-to“. In this particular post, the options to segregate tasks for creating and maintaining master data on one role and the hold status on customers and vendors in another role. The way how to achieve it is different for customer and vendor master.
Scenario
In many cases, there should be a split between access for creating and maintaining customers and vendors and their hold status. In most cases e.g. a purchasing agent is not allowed to change the hold status, but the accounting manager is allowed to control this. You can manage this via security configuration. Depending on the more strict requirements, you can also support it with additional Segregation of Duties rules.
Customers vs Vendors
As mentioned in the introduction, the way to achieve the split is different for customers and vendors. On the customer details form, there is a field with a pre-defined hold level which can be changed like any other field. Contradictory, on the vendors, the field is not editable and it is managed via a menu item on the menu bar. The field is not editable here.
The difference is because, on the vendor side, there is an option implemented to provide a reason code. In addition, you have the option to apply the status in all other legal entities where this vendor is set up. In my opinion, it makes sense to have the same feature implemented on the customers. However, that is not available today. For the security of the on-hold on customers, you have to configure table and field permissions. For the vendors, it requires a menu item security configuration, so it is a change on privileges.
Required changes vendor on-hold
As mentioned, the security permission for a menu item should be used to control access to the On-hold menu button. After short digging into the form design and security permissions, the menu item is part of the privilege Maintain vendors.
Simply changing this privilege will probably not have the correct result as this is linked via the duty to the next roles:
- Accounting manager
- Accounts payable manager
- Purchasing agent
- Purchasing agent – public sector
- Purchasing manager
If you have already customizations, also other roles might be impacted. Suppose, we want to have the Accounting manager and Account payable manager be able to change the hold status and the other three personas not. There are two ways of achieving this requirement:
- Duplicate the security privilege and duty. Then on the copied privilege remove the reference of the display menu item VendOnHoldUpdate. Link the new privilege to the copied duty. Then you can replace the original duty on the purchasing roles.
- Create a new privilege with a reference to the display menu item VendOnHoldUpdate and set deny permissions. Link this privilege to a duty or directly on the role. You can also create a new role with only this privilege. If you create a new role, you can link this additional security role as sub role to existing purchasing roles or assign them to the users.
When you are using Dynamics AX 2012, you can only use the first option as the deny permissions were only added in Dynamics 365. When you are using the deny permissions, you might not need a separate Segregation of Duties rule as the deny option will overrule all grant permissions from other security settings active for a user.
Required changes customer on-hold
In Dynamics 365, at this moment, the only option is to set deny permissions on the Update access level of the field. As example, I created a deny role for the customer on-hold and added a new privilege with only a table permission for the field Blocked of the table CustTable. Only the Update access level was set to deny. All other access levels for the table and the field are still on Unset. In this case, the table permissions and read permission of the field will be controlled by all other security roles assigned to the user.
In Dynamics AX 2012, you can override table and field permissions on the roles (or privileges) and set the access level to Read.
Now, when you set up different trial users with roles like, purchasing manager, accounts receivable manager and accounting manager, you will notice the differences in access.
I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.
That’s all for now. Till next time!
Hi, I am having trouble with creating a custom role whose only ability is to add a vendor. Right now, they are able to press the “New” button on Accounts payable > Vendors > All vendors tab, but then they are not able to edit the fields once they are in that page, such as Vendor account, Name etc. Wondering if you can help with this?
Thanks,
Zoe
Hi Zoe,
You posted the same question on the Dynamics Community forum. I have provided my thoughts on your question: trouble giving access to enter new vendor info
Hi, thanks for your post. it helps me.