Restrict Entity Read/Creation/Deletion/Update in Model-driven App

[NaCarns]

Hello.

I've been scratching my head for days trying to figure this out, and unfortunately I'm not getting any closer.

1) Is there a way to restrict access of users in one Area of a MDA to another Area? I'm separating departments by Areas so I would like a user from Department (Area) 1 to not be able to access, create or read entities from Department (Area) 2. Is that possible at all? 

2) Can I set it up so that a user from one department (Area) can only read entities from another Area? 

3) When I create records/data in entities from one Area, it also shows in another Area. Is there a way to create records of the same entity in one Area that won't show in another?

Any help would be appreciated. Sorry if this is the wrong section to post this, please move this if necessary. 

[ChrisPiasecki · Accepted solution]

Hi @NaCarns,

1. Security roles will control what your users will be able to see. If the security role(s) you assign to Area 1 does not have any read/write/create/delete access to Tables from your Area B, then they won't see them in your model driven app or via any other way.

2. You can use Business Units to logically separate your areas. When configuring your security roles, you can set Read access at the Organization level scope, and create/write/delete/assign/etc. at the Business Unit level. This will allow them to only modify records owned by users in their business unit ("area"), but still be able to read all records in that table.

3. Same concept as #2, use of business units and security roles to scope permissions at the correct level. In this scenario you would also set read access to be at the business unit level so they don't see records from other business units ("areas").

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

[NaCarns]

Thank you for the answer. This cleared a lot of my doubts. There's one thing I'm not fully understanding. So I separate departments by Business Units, and users part of a BU will be assigned a security role with the relevant permissions. 

Thing is, I need to have my departments separated by Area (the bottom left option in a model-driven app). If a user is in the Area called Department A for example, and he's part of a BU called Department A with his own security roles, how would the Area be "linked" with the BU? How would it be known that this user, if he clicks on the Area called Department B,  can't modify the entities there for example? Note that many departments will share the same entities. Is there a way I can link the Areas with the BUs? So I kind of want 'Area-level security'. I'm sorry but that's the best way I can explain this with the level I am at now.

If it's confusing, I'll try and explain it better. Thank you.

[ChrisPiasecki]

Hi @NaCarns,

The navigation you refer to just controls what tables/dashboards/custom pages they navigate to. They aren't specific to business units or other filters. The records they see in views will be automatically filtered based on security (read), plus any filters you apply to a specific view. If they opened a particular record, it would be locked if they don't have write privileges. Or if they are in the view and they highlight a specific row, then the Edit button at the top command bar would not be available either.

If your "areas" share only some common tables but fundamentally do their work differently and have many other custom tables that only they need to use, then I would suggest creating separate Model-Driven Apps that are focused for a very specific use, rather than one common monolithic app.

You can create views, forms, dashboards for your tables tailored for your business areas, then you can choose which views/forms/dashboards you want to include in each app.

Hope this helps..

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

[NaCarns]

We did suggest to separate the application but one of the requirements of the clients, was a 'landing page' for each of their departments in the application. We assumed that they meant they require an app where different departments can navigate to their section through an options menu like the Areas. I can summarize their requirements if you want: 

Spoiler

They want an interactive performance management dashboard that provides comprehensive visual representation of an organization's KPIs, metrics, etc to senior stakeholders. Dashboard will include a repository section that allows any user to access and view resources, internal documents, etc.

Their requirements for the data entry portal (the application we were discussing) are as follows:
- develop online portal for data entry (not a website)
- user roles/groups should be defined for data input (manual input or Excel upload)
- portal should be accessible through their current D365 CRM system. Their departments should each should have a landing page on the portal
- KPI data captured by their existing CRM system should be linked and fed to the portal directly - capture and provide audit trails of all user activity

Power BI will be used for dashboards so they want to link Dynamics 365 with it.

If this is too tedious or demanding to help, it's fine. You've helped me enough. 

Many thanks.