Recently, I was speaking about eXtensible Data Security (XDS) at a meetup session for the Pakistan Microsoft Dynamics 365 and Power Platform Community. I did a similar session several years ago and created three examples back then as part of the demonstrations of what would be possible to achieve with this framework for record-based security. For this recent session, based on a question on the Dynamics Community forum, I created a new example for restricting access to the projects and related information for a person who is one of the responsible persons. In this post, I will provide some more background information on the functional and technical details.
What it does functionally
When you open the My projects list page in Microsoft Dynamics 365, the projects are filtered based on the three responsible fields on the project details. Only the projects where you are a Project Manager, Sales responsible or Financial responsible, will be presented. This is a help to get focus with a limited set of projects.
There is no security involved here. The list page is opened with a query set that will not show all projects. You are still able to open other forms and see details and transactions from all other projects.
If you need to restrict this, it can be achieved with a security policy on the Project table and related details, such as transactions or data entities. The example which I created for the project responsible security has record security on the project and base transaction tables. Also one data entity related to the project master data is constrained. In the technical details below, you will find more information on how to restrict more tables and views.
With the security policy enabled, now David in this demo will not see all project anymore, only where he has a responsible role.
In addition, when opening, for example, the Hour transactions inquiry form, only the transactions related to the project are visible. The strength of XDS in Dynamics 365, is the ease to add multiple constrained tables on a single security policy.
The technical part
When creating new security policies, you first have to think of what tables, views, and data entities need to be restricted and if this is valid for all roles. Also, how can the policy find the user context? When analyzing the project module, there are quite some tables linked to the projects. In my demo, I restricted it to only a few transaction tables, but you can also think of restricting e.g. budgets and estimates.
The user context is in this example very simple. When you open the My projects list page, there is a query range in use which can also be used for the security policy to limit results to the project responsible.
The range value used is an advanced filter option where you can provide SQL statements and call static x++ methods. When the list page for My projects is opened, the menu item has a query specified which is the reason for having the filter applied on the list page. Now, one part of the security policy is creating a query with the restrictions for a user. When analyzing this query, it can be re-used for a security policy. The first data source of the query is the ProjTable and it is restricting the projects based on the persons set as responsible.
As next step, we have to create a new security policy and set the primary table value to ProjTable and link the query. To be able to prevent users from viewing projects not belonging to their responsibility and also not being able to create new projects without setting himself as responsible, you can set the property Operation to AllOperations. Don’t forget to enable the Constrained table property.
Now you can add related tables which also needs to be constrained. In my example, I added just a few as a start. If you need to limit records in more tables, related to the projects, you can add new constrained tables.
In this example, I didn’t provide a role context, meaning that the policy is active for all roles. With help of the context and role name properties, you can finetune the policy enforcement.
All objects for this project responsible security example can be found on my My OneDrive DynamicsShare. If you want to explore the examples, feel free to download and use them. The software is provided as-is and you cannot obtain any rights if something is not working correctly. You have to ensure you will install the examples in a separate environment first and test it carefully. If you have questions or feedback, feel free to add comments or send a message.
Create the security policy in 5 minutes
Apart from the analysis part, build, test, and deployment times, you can create this XDS policy in 5 minutes. The number of tables and views to be constrained will also determine how much time you need to create the security policy. You can watch the video below for the demo.
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!