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!
Original image by mrtapp1 from Pixabay
Image by Dave Tavres from Pixabay 
Hi, I’m using the D365FO 10.0.17 version.
I had followed the steps you shown in the video one by one already, but it does not work after built and deploy to the UAT environment.
I even also downloaded your example and modified based on our environment and deployed, still not work.
Is there any other setup ? is there any other settings i need to enable in front end or back end ?
Please advise, many thanks
Hi Phyllis,
Can you describe what you mean with it does not work? Does it show all projects or none? What roles are assigned to the user? Ensure the user does not have the system administrator role assigned.
Hi, many thanks for your replies, i was using the system administrator to login the system, and so, just all projects still be loaded and shown..
Now, i’ve tried to use another user (without system admin role), then found the security policy work now….only for those projects with that Project Manager shown.
Thanks for your information.
Hi Phyllis,
Thanks for the feedback. Glad it is working now for you. Remember for the next time that the system administrator role is bypassing all security, so also XDS.
Hi, André. As far as I can see, the security policy is not connected to any role so that once created, it will apply to all users (except sysadmins) and nothing can be done from the client about it (talking about D365FO now), one must go through Visual studio to modify or deactivate it?
Hi Alexey,
Correct. In my example I didn’t restrict the policy to a certain role as that can be different per environment. You can go to Visual Studio and change the settings to restrict it to one specific role or multiple roles using the context string.
Hi Andre,
I have done a small customization to assign multiple locations to user in user master form and used XDS to restrict users from financial dimension (location) in all forms. So now users can not see transactions other than assigned locations to them in any form however this is not working in reports as users can see transactions to all locations. I know XDS has limitation in Temp table due to which its not working in the reports.
Please suggest me if there is any work around to restrict users from seeing all transactions in the report except assigned location.
Hi Samarjeet,
Can you share how the report is created? Is it query-based or do you have a data provider? Are you using the constrained table directly or are you using a view?