Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Tom Carr]

I have a question for those of you who have multiple sites using D365 regarding how you’ve set up security across those sites.  My question is this:  what is the recommended way for multi-location D365 F&O organizations to set up security so that their users in one location don’t have access to information in another location?  Our situation is that we currently have one legal entity with 5 physical locations.  Those sites function as independent businesses but they are supported by shared services in supply chain, customer service, finance, etc so we want to keep them in one legal entity.  However, we have already experienced issues with controllers accidentally logging journal entries to another location, production supervisors being confused by looking at information that includes other sites’ data, etc.

Obviously, we are far from unique here. I’d assume that a fair number – if not the majority – of AX/D365 users have more than one physical location so what is the desired/recommended way to set up user security so that a user in one plant isn’t viewing information or potentially even updating information for another location?

We have discussed this with our implementation partner and also with our Microsoft team and have been shocked that there doesn’t seem to be any way in the system to accommodate this without pretty extensive coding and/or customization.  Alternatively, we could split every site into its own legal entity but that would introduce a host of other concerns that make it a pretty terrible option for us.

Is there a way to set up security at the site level within a legal entity?  Or do other companies just keep it at the legal entity level and hope to address potential conflicts with user training and site-level filters on screens?

Thanks!
Tom

——————————
Tom Carr
HBD Industries
Dublin OH
——————————

[Ludwig Reinhard]

Hi Tom,
If you already discussed with MS you might have heard that you can bind the user access to a hierarchical structure that can be made up of organizational units. Have you considered this option for restricting the usage? It’s not automatically synced with sites but might be a comparatively easy option to implement.
Best regards 
Ludwig

——————————
Ludwig Reinhard
Sycor
Goettingen
——————————
——————————————-

[Zvika Rimalt]

Dr Ludwig, could you please elaborate as to what you mean by “bind user access to organizational units”? what in practice does that mean? a simple example would be much appreciated.

——————————
Zvika Rimalt
Functional Consultant
Vancouver BC
——————————
——————————————-

[Ludwig Reinhard]

Hi, 
I referred to the following feature that allows binding sites to findims, then organizing findims in hierarchies, assigning them with a purpose and then restricting user access by the seleceted elements of the hierarchy. See the attachments no 1-4. Not sure if this fixes the issue but it might be worth checking this option. 
Best regards, 
Ludwig

——————————
Ludwig Reinhard
Sycor
Goettingen
——————————
——————————————-

[André Arnaud de Calavon]

Hi Tom,

To prevent users from accessing wrong information, you have to implement eXtensible Data Security (XDS) or different legal entities. Using XDS, you can limit access on records within legal entities. Standard security is only limiting access on legal entities.
You can read about XDS and some examples which might be also useful for you on my blog: https://kaya-consulting.com/extensible-data-security-examples/
The setup provided by Ludwig could be used to create the XDS policies. One example in my blog is restricting data based on the organizational hierarchies as well.

——————————
kind regards,

André Arnaud de Calavon
Solution Architect, Microsoft MVP – Microsoft Dynamics Business Solutions
——————————
——————————————-

[Zvika Rimalt]

Hi Andre and Alex,

Have you seen the approach of XDS used effectively in the context of the question?

I am trying to think through that approach, with my limited familiarity of XDS, which I understand performs filtering on tables, based on policies.

Let’s say an employee is set with access to site A but not to site B
and let’s say there is a transfer journal to move inventory from site A to site B.
wouldn’t the existence of XDS policy linked to site means that the employee cannot see the transfer journal line, as it was “filtered” by the fact it contains a selection of “site B”?

——————————
Zvika Rimalt
Functional Consultant
Vancouver BC
——————————
——————————————-

[Alex Meyer]

Zvika,

You can basically think of XDS of almost like a WHERE clause in SQL. I’m not sure what the table structure looks like around the particular process you laid out but basically a user would have access to all objects within the table and then XDS can be added to filter those results further.

If the user is needing access to move inventory or any other object between sites, areas, or legal entities then they would need access to both source and destination in most instances I believe. So in your example below either the user would need to be assigned to both sites or another user with that access would actually have to perform whatever process they are looking to perform.

——————————
Alex Meyer
Director of Dynamics AX/365 for Finance & Operations Development
Fastpath
Des Moines, IA
——————————
——————————————-

[André Arnaud de Calavon]

Hi Zvika,

This site/warehouse question is one of the biggest issues here. In the example, I shared in one of my blogs, I took some assumptions. You can actually have the option to view all records, but only edit/create based on the security policy. Then also implement security on or the from or the to warehouse/site.
For your reference: https://kaya-consulting.com/extensible-data-security-examples-secure-by-warehouse/

——————————
kind regards,

André Arnaud de Calavon
Solution Architect, Microsoft MVP – Microsoft Dynamics Business Solutions
——————————
——————————————-

[Alex Meyer]

Will 2nd what Andre said, XDS seems to be the solution you are looking for here. This adds an additional layer of security beyond what you would get via the normal security model with restrictions by legal entity. Basically a user would only be able to see or interact with records for their particular location, geographical area, etc even though by the security model they should have access to all. His blog is a great resource on the topic.

This Microsoft doc also goes through what it would look like: Overview of Security Policies for Table Records

——————————
Alex Meyer
Director of Dynamics AX/365 for Finance & Operations Development
Fastpath
Des Moines, IA
——————————
——————————————-