The Dynamics 365 security model
When it comes to data, security defines who has the right to do what on a record in the respective context of the user and the data.
- Command bar buttons
- Business Process Flows
- The sitemap (or sitemaps, since 8.2, thanks to Business apps)
- Views (since 8.2, thanks to Business apps)
- Charts (since 8.2, thanks to Business apps)
Standing at the crossroads
Data security must be conceived as a meeting point between data and the user’s rights. The security model’s backbone, that enables those meetings, is the business units hierarchy.
I will elaborate more on importance of the context of the user and the data in an upcoming article.
Customizing views and forms IS NOT securing data
Once configured, the security model applies regardless of the entry point of your users: through the Web interface, the Web Services, the SQL Filtered Views (On-Premise), the mobile application, the reports…
It is important to understand that forms that are associated with security roles do not restrict in any way access to CRM data. Contrary to field level security, forms are just an ergonomic presentation of your data (UI). The same goes for the columns you chose to display in a view, or the filter you decide to apply to it. Any user can bypass them by doing a simple Advanced Find.
On a similar note, resourceful users who have a read access to CRM data can access it through the Dynamics 365 Web Services, and thus be able to export them one way or another, even if the “Export to Excel” button is hidden to them.
Security can only be configured server-side, through the configuration of your users’ rights (business units hierarchy, users/teams configuration and their security role, entity relationships, field level security, positions…), and if necessary through custom logic that is executed with Plugins or Workflows.
Example of hacks
This injection can be done with the console of your browser, or by minifying this code and copying it as a bookmark URL (more examples here).