Alex Meyer
Forum Replies Created
-
Rocio,
This is a great question. I do not think this exists as most of the individuals / companies that have created this offer this as a paid offering / service (speaking as someone who has led the creation of SOD rulesets in the past).
However there are some typical scenarios that are ‘ERP agnostic’ that you can help to create this, for example:
– Access to maintain master data and then transact against it (ex: ability to maintain a vendor and pay that vendor)
– Access to setup/configuration of a module and then transact within it (ex: ability to update procurement and sourcing parameters and post purchase orders)
One last point, the out of box SOD functionality from Dynamics has a fatal flaw in that it does its analysis at the duty level and not the securable object level. This leave adequate opportunities for false positive / false negative results in the result. Some companies can accept this risk but others in more highly regulated industries might not be able to.
If you have any other questions about this feel free to reach out.
Resources:
-
There’s not a set list as each client will have a different set of tables based on the features and functionalities they have enabled/configured.
Here is the current list of tables and fields from a 10.0.38 development environment I have, I generated this by creating an X++ batch job that queries the AOT for object metadata:
https://1drv.ms/x/s!AuaIh49EjUqUvE19zqM6PR0AHSLl?e=EcGcHK
1drv.ms
Dynamics 365 for Finance and Operations Table and Table Fields.xlsx - Microsoft Excel Online
Dynamics 365 for Finance and Operations Table and Table Fields.xlsx - Microsoft Excel Online
-
Amber,
This feature is built into D365FO although it is a ‘hidden’ feature in that you have to manually enable it via a license configuration.
I have written about the process here and the potential issues with this here: https://alexdmeyer.com/2019/02/10/configuring-azure-ad-group-security-in-d365fo/
alexdmeyer.com
Configuring Azure AD Group Security in D365FO - Alex Meyer
In AX 2012 you had the ability to use Active Directory groups to help manage security, but what if you wanted to use Azure AD groups within D365FO?
-
Richard,
The ideas of a ‘worker’ and a ‘user’ record are separate things within D365FO.
A user record is required for someone that is logging into D365FO, a user record is also where role assignments occur which will dictate what access this user has.
A worker record is used within D365FO is used for workflow approvals as well as certain external portals throughout the system (production floor execution mobile app, warehouse mobile app, etc). These individuals normally interact within D365FO through a mobile device and have extremely limited functionality they can perform, therefore workers do not require a license within D365FO.
The reason these are separate ideas is because you have have someone that needs to be a worker within D365FO but does not need a user record (saving on licensing costs). However you can associate a user and a worker record (if this is possible) via the Person field on the user record.
