Security how-to: A purchasing agent is not allowed to view employee expense transactions

This is the first scenario in a new blog series about “Security how-to“. In this particular post, a possible security setup for the next scenario will be explained: “A purchasing agent is not allowed to view employee transactions”

Scenario

It is quite common to setup your employees as vendor in Microsoft Dynamics. For example when you implement expense management, it can be used to create balances on the employees and use the vendor payment journal to reimburse the expenses to the employees. A purchasing agent usually has at least view access on the vendor form. From this form, depending on the rights, the purchasing agent would be able to view the vendor transactions. In this case, it is not only about the transactions, but also your would like to protect private data like postal addresses or phone numbers. This is e.g. the case when you want to be GDPR compliant. For sure, you would like to prevent a purchasing agent from changing bank accounts from the employees if they are setup as vendors. When designing the security, you always have to take care of securing outgoing cash flows. This will be a recurring attention point in all upcoming scenarios.

Now we know the full scenario, there should be a decision whether the purchasing agent would be able to view all vendor records including the employees or just the trading partners. My initial thought would be hiding all records who are an employee. This approach will be described more in detail.

Microsoft Dynamics 365

In the current Microsoft Dynamics 365 Finance and Operations applications, it would be possible to implement data security policies. An user will get access to a certain menu item, but there will be a constraint on the individual records. These policies can be creating with help of the Extensible Data Security framework (XDS). Note that this option requires development and deployment of a customization.

Before implementing the XDS policy, we have to know how to distinct the employees from the trading partners. Usually, the vendor groups are used to make this grouping. So, the base table to secure would be the Vendor groups table or the Vendors table directly and constrain other related tables. Is there a best practice to choose between these tables? Yes, for sure you have to consider possible performance impact.

A side example before coming back to the real requirement:

If you have a requirement to go several levels deep with table relations, then the query which will be executed on the database to retrieve the records will be more complex. For example, when the back-order lines needs to be restricted based on the vendor group, the logical table chain will be: Purchase order lines, Purchase order, Vendor, Vendor group. If this was the case, then it would be probably better to start on the Vendor table. In that case a query on the order lines will have 3 table joins instead of 4.

Surprisingly, the Purchase order and Purchase order lines tables do have a physical field for the Vendor group. So, in this side-example, I would choose the Vendor groups as the primary table and set the Vendor, Purchase order and Purchase order lines as constrained table on the first level of constrained tables.

Now back to solving the requirement to prevent purchasing agent to see the employee expense transactions. I do assume the vendor grouping is the key to indicate if a vendor is also an employee. If you are using a coding system which is different per environment or legal entity, using the vendor group hard-coded on the data policy query is not recommended. You can consider creating a parameter field to indicate which vendor group is used for employees or create a field on the vendor groups (No/Yes) to indicate if it is related to employees or not. That information can be used to create the data policy query.

When the policy query is ready, you can create the security policy where the Vendor group, Vendors and Vendor transactions tables will be constrained. It will be a design choice to constrain the tables Vendor group or Vendors itself. As mentioned above, my initial preference would be constraining the vendors who are an employee. In that case, a purchasing agent is for sure not able to view private details.

Would there be another option to achieve it? At this moment not. I’m desperately waiting for the implementation of securing the Global Address Book features in Microsoft Dynamics 365. This has not been moved yet from…

Microsoft Dynamics AX 2012

In the previous version, AX 2012, there was a feature called Global Address Book Security. Using this feature, you can achieve the requirement without a development effort. The option ‘Secure by Address Book’ is fulfilling the requirement. It would require to setup Address books and tag vendors with one or more address books. Using Teams, you can assign which persons will have access to what Address books and in this way who will see what vendor records. There is one pitfall here. It will restrict to see vendors and other parties based on the address books. However if there is no Address book tagged on the vendor, it will be visible.

Apart from this address book security, you can also use the option as mentioned above for Microsoft Dynamics 365.

There is more…

The Security of the global address book is not deprecated. It has not been moved yet to Dynamics 365. You can read it on the next page: AX 2012 features that were postponed. There are some technical reasons why it is not possible today. Enabling the security on the global address book did change a property on several security policies (XDS) in the AOT. As the development environment has been separated from the application, the option to change the object is not possible. It would require a change which, in my opinion, is not impossible. Microsoft is aware of the requests, but did not implement it on Dynamics 365 yet. You can vote on the idea Re-instate securing the global address book by team as per 2012 to get it prioritized by Microsoft.

In this post, I have not provided a demo or code examples how to create a possible XDS policy. If you try to create one yourself and get stuck, you may contact me or leave a comment below.

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!