Arek Socha from PixabayFor a longer time, I was considering documenting several experiences how to setup specific security topics in Microsoft Dynamics 365 Finance and Operations and Microsoft Dynamics AX 2012. Since I started implementing Damgaard Axapta 2.5 in 2001, I have done a lot of security setup and had sometimes some complex challenges. This post will be a table of contents for all documented scenarios and will be updated when a new blog post in this series will be published.
Background
Some security scenarios are quite common in implementations, but require some setup which is a bit different from just the basic artifacts as security roles, duties and privileges. In the scenario’s I will try to provide as much as possible details if there are different approaches for Dynamics 365 versus AX 2012.
I have a backlog of several scenarios, like how to restrict a purchaser from viewing details of claimed expenses if workers are setup as vendor or how to prevent someone to be able to approve his own timesheet.
If you have some scenarios where you need help or just want to know how I would solve it, please leave a comment at the bottom of this post or send a message via the contact form. I will review the request and will add it to the backlog.
Scenarios
In the table below, you will find links to the documented scenarios. Note that there might be more options to solve a certain scenario.
| Date published | Scenario description |
|---|---|
| 2020, August 31 | A purchasing agent is not allowed to view employee expense transactions |
| 2020, November 8 | A purchasing agent is not allowed to maintain vendor bank details |
| 2020, December 8 | Only a finance user is allowed to change the on-hold status of vendors and customers |
| 2021, February 10 | Only finance users are allowed to see cost prices in Dynamics 365 Finance and Operations |
| 2022, November 18 | Disable change of session date for users |
New scenarios will be added in the coming period. You may come back regularly to visit this page to read how to secure different scenarios.
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!
Image by Arek Socha from Pixabay 
Bru-nO via Pixabay
Image by Kris from Pixabay 
Original image from Jan Alexander on Pixabay 
Image by Gerd Altmann on Pixabay
Arek Socha from Pixabay
A very common scenario we have, is that customers want purchasing agents to only be able to see items from groups for which they have specific permissions. eg. Purchaser x can buy cling film and crates, but Purchaser y can buy engineering parts, and Purchaser z can buy apples and pears.
As far as I understand, the only way to do this, is to build specific XDS filtering with code, even though this seems like it ought to be a very frequent scenario.Is that right?
Hi Andrew,
Thanks for your contribution. You can indeed filter data with help of XDS, coding, or a combination. You can also consider using approval workflows and set conditions where it can check for incorrect items. However, this is also a tedious task to set up and maintain in the workflow configurations without customization.
Today, there is functionality to have approved vendors by category. A similar feature for internal purchasers and items (per category, item group, or buyer group) is not available out of the box.
You are correct that in many companies people are responsible for the procurement of a specific part of the assortment. In most implementations I have done, it was implemented via an approval flow or another customization. The customizations were done in the time there was no workflow or XDS available.
Hi Andre’, not 100% sure if this is the appropriate place to pose my question, but here goes.
The issue is around duty creation, and the best approach for our purposes.
As I’m going along in implementing 365(we’re coming from AX 2009), we seem to be leaning toward creating a large number of discrete duties, vs lumping many into one.
The idea being, if there’s a chance we’d reuse that duty in another dept, we’d prefer to have separate duties. But, some contend that we should consider creating larger duties, combining functions, when those functions normally work together.
I’m curious to know if there’s an argument for going either way with duties?
Is there a reason to NOT create more, than fewer duties?
Example:
2 duties might be:
Create_Warehouses
Create_InventoryAisles
Even if Create_InventoryAisles is normally a part of creating a warehouse, we’re thinking of separating them, in the event that someday, we might have a need for a duty where someone is allowed to create an aisle, but not a warehouse..
Does that make sense? or totally confusing…
Thanks much for your expertise!
Rich
Hi Rich,
You have a great question where one answer fits all will not be applicable. It depends on preferences and maintainability.
The more security objects you create, the more you have to maintain. Your example makes full sense on the privilege level. For a duty, initially, I would have it combined when this is the current defined process. Only once there will be another new process in the future, I would consider breaking them up. When defining duties, you also have to think of the ability to segregate tasks for audit purposes. Mentioning this topic, then it could make sense to have a duty to be able to maintain vendors, but not the vendor bank accounts. Maintaining bank accounts could be part of another smaller duty.
I do hope this will help you in defining your own preferences what would suit your company the best.
PS it is OK to ask your question here, but you can also post the question on the Dynamics Community forum where are more volunteers which could all share their experiences and opinions.
André