How to elicit security model requirements for your Dynamics 365 or Power Platform project

When eliciting requirements with your client, you will likely discuss some aspects of the security model. What can the different types of users see in your application? What kind of records can they access? Can users from different departments or teams edit each other’s records? etc.

Thank you Sachin Dakare and Bilal Saeed for submitting your questions about this topic which inspired me to write this article.

Before sharing my thoughts on the topic, I decided to do some more research on the type of challenges that we (Dynamics 365 and Power Platform professionals) face when eliciting and documenting requirements related to the security model. You can see the results from my LinkedIn Poll below.

Based on these results, I decided to focus this article on the key questions (and supporting scenarios) that we need to cover when eliciting requirements with our stakeholders.

I will also share the approach I use to elicit security related requirements so that you know where and when I ask those specific questions.

My approach

Start by educating your audience about the basics of how the security model works in Dynamics 365 or the Power Platform.

Your stakeholders need to understand enough to be able to give you valuable information. You might also need to take time to refresh your own memory on how the security model works. You can find some good materials under the following resource from Microsoft Learn: Review the security model for your Dynamics 365 solutions – Learn | Microsoft Docs

Then you will need to understand enough about your client to prepare and discuss scenarios where you can ask specific questions about your client requirements.

This is an iterative process, so start with an initial workshop to cover simple scenarios. Then if the requirements are more complex, organize additional workshops where you can elaborate on more advanced concepts and cover the complex scenarios.

After each workshop, document the requirements.

At the bottom of the article, you can find a link to download the PowerPoint and the Excel Matrix I use to workshop and document the requirements.

Educate

Here are the concepts I typically cover to educate a new client on the basics of how the security model works in Dynamics 365 or the Power Platform.

Understand

Once you’ve presented and explained the basics, it’s time to ask the following questions so that you can prepare your scenarios.

Do we need Business Units?

Sample questions:

• Do we have multiple departments (or branches) using the App?
• Will the departments work on the same types of records? Ex. Will 2 different departments use “Cases”?
• If yes, do we need to restrict access to data between those 2 departments? Ex: Do we want to restrict “Department A” from updating cases of “Department B”?

Define the Security Roles.

Sample questions:

• What user personas (or user roles) will be using the App? Ex: “Case Manager” or “Sales Rep.”
• Can those personas do the same actions in the App? This is to validate if we could reduce the number of “Security Roles” in the App. Sometimes your client will list all the possible roles/titles of the company, however, if they all can do the same in the App, you might as well just create 1 security role for all those types of users.
• Are the personas the same for every department? Ex: Will we have a “Case Manager” in “Department A” and “Department B”?
• Do we have different levels of access based on seniority? Do we need a manager or director to be able to see or edit a wider range of records?
• Do we have a Business Admin that will administer some of the configuration data?

Define the main Tables / Entities affected by the security model.

Sample questions:

• What are the main “Tables / Entities” that the identified personas will be working with? Ex: If we talk about the “Customer Service Rep” role in Dynamics 365 Customer Service”, the main tables are “Cases”, “Accounts”, “Contacts”, “Knowledge Articles”, etc.

Real life scenarios

Now it’s time to run through a few real-life scenarios.

As you want to guide our client in this journey, start with simple scenarios first and gradually increase the complexity. I for example avoid discussing “sharing” or “field level security” at the very start.

Document

Use the provided Excel sheet to document your security roles requirements after each workshop. Remember to keep updating and iterating throughout your documentation and design process.

Important to remember

Simplify, simplify, SIMPLIFY.

Dynamics 365 and the Power Platform provides an extensive set of tools to let you achieve the most complex security related requirements. However, before choosing to implement a complex model, challenge the necessity to do so. Try to have the simplest possible model that meets your MUST HAVE requirements.

Security modelling can be a difficult topic to understand if your client’s requirements are complex. In my experience I have seen that close to 80% of my client’s requirements can be met with a simple model. It’s often the last 20% that have some extreme scenarios and are adding a lot of complexity.

Remember that someone will have to maintain the security model too as new tables will be created or teams and roles will be changed. ​

Access vs Filtering

Make a clear distinction between restricting access to records versus filtering records from views: If your client is worried that specific roles or users will see records that are not relevant to them, use filtering records instead of restricting access to them.​

Activity table ownership

Be mindful that the privileges you apply on the “Activity” table will apply to all the activity types like email, task, appointment, etc.

Organization Ownership

When creating new tables, I personally avoid using the “Organization Ownership” unless I am 100% that I won’t need to apply some security access privileges later.

After you have created your table, you won’t be able change the ownership type. If you later need to change the ownership to “User / Team”, you will have to delete your table and recreate a new one. Which is a very painful experience if you are already live with that table.

Reporting Requirements

Discuss the data sources that your users will need to have including access to Power BI dashboards, Reports, Export to Excel and general report access requirements. Thanks for your suggestion Sharon Smith 😊

Templates

Here is the link to download the PowerPoint and the Excel Matrix that I use during my workshops and to document the requirements.

What’s next

I hope that you enjoyed this article as much as I enjoyed writing it. I initially intended to write a single article but as I was writing, I realized how much more depth and detail could be covered about this topic.

My next article will cover some considerations on “How to DESIGN security model requirements for your Dynamics 365 or Power Platform project”.

Let me know in the comment section below if there are any other topics, related to the security model, that you would like me to write about.