Tag Archives: Security

The right questions to ask when designing a security model in Dynamics 365

Where to start when it comes to security in Dynamics 365 Customer Engagement?
In this post I will help you ask and hopefully answer the key questions that arise when you design a security model.
I will also provide important warnings to consider and I will give you a simple method on how to lay down on paper the foundations of your security model and its business rules.

Dynamics 365 Security Design

What type of owner for your records?

It’s a crucial question. As I mentioned in my last article dedicated to the security context, the owner of a record defines the record’s position in the hierarchy of business units, and to which user or team it is linked to.

A user?

This means that the record belongs to the business unit of its owning user.

This is the default behavior in CRM, but is it always for the best?
Pay attention to scenarios where users are cross-departments and could work on records that can be functionally linked to different business units.
Example: I am part of the global management of a firm and as such, I sit on top of the hierarchy. At the same time, I work on an opportunity that is functionally related to the “Analytics – France” business unit. How to make sure that users belonging to that business unit also see my opportunity, if it is technically linked to a business unit above them (mine), and if they can only see opportunities that belong to their business unit? (You’are allowed to draw!)

A team?

Teams can become quite handy when it comes to dispatching data in the right place in the hierarchy of business units.
This also lets you manage independently how you dispatch users between business units (and this might not be even necessary!)

On the other hand, choosing to assign data to teams requires a bit of consideration on how to (possibly) automate these assignments, depending on business rules.
Example: when an opportunity is related to the “Business Apps – France” business unit (through a custom lookup), then assign the opportunity to the default owning team that is configured on this business unit.

A few good questions you should ask…

Beyond the classic “who should do what?”

  • Where to dispatch my users? Sometimes it is not even necessary to dispatch them in business units, especially if your security model is based on teams.
  • Where to dispatch my data? That’s the critical point

Don’t forget!

  • Who can see notes?
    Be careful with received ideas!
    Note security is not inherited from the entity it is attached to.
    They also have an owner and should not be forgotten in your security model. Otherwise you might have a surprise one day if a user makes an advanced find.
  • Who can see activity feeds publication?
    Just like for notes, visibility on publications does not depend on the visibility of records they are attached to.
    In fact, the Publication entity does not have an owner… everybody can see all of them, provided they have at least a read privilege on the entity.
  • Can we distinguish the rights on different types of activities?
    It is not possible to have different privileges on different types of activities.
    The security of an email, appointment or task should be handled in a single way.
  • What is the impact for the Outlook synchronization if my activities belong to teams?
    Be careful with Outlook default filters. They are often based on the owner.
    You should review each type of activity individually and update your organization’s default filters accordingly, for example with this great tool by Tangy Touzard: Sync Filter Manager.
  • How to manage security for a record that can be assigned to anybody in the organization?
    For example, a task can be assigned to different people, or a case can be handled by multiple users in their life-cycle.
    You should carefully review the path and life-cycle of your records, and make sure that they remain visible to the right users during their processing.

Warning: designing and implementing a security model can take time!

We rarely plan enough time to handle complex security models, thinking that it’s “just” configuration.

Security can require quite some work:

  • Automatic creation and configuration of owning teams
    Especially if your model is complex, with a large number of business units that evolve in time.
    Keep in mind that teams also need a security role in order to own records!
  • Automatic assignment of records based on business rules
  • Automatic configuration of users based on their profile

Document your model and create a data security inventory 

Create a spreadsheet with the entities that you use in your projet, their type of owner, and how the owner should be determined.

For example:

Entity Owner Business rule to identify the owner
Contact Team Depending on the contact’s country:

  • Contact > Country > Country’s owning team
Lead User The user who creates the lead (default behavior)
Account Not relevant, as in this model all users should see all accounts
Opportunity Team Depending on the managing department of the opportunity

  • Opportunity > Department > Department’s owning team
Note User / Team It depends:

  • If the note is attached to a contact or opportunity, then the note should be assigned to the same owner as the contact or opportunity
  • If the note is attached to another kind of entity, then the owner should be its creator.
Product Organization N/A
Price List Organization N/A

Dynamics 365 Security: context, context, context!

Have I mentioned how important the context is?

Whenever you address a security question in Dynamics 365 Customer Engagement, there are always two contexts that you must take into consideration: the data context and the user context.

LockThe data context: it is provided by the record’s owner but also (and it’s very important), by the Business Unit of its owner (whether it is a user or a team).

The user context: his or her Business Unit as well as his or her different security roles. Whether those roles are assigned directly to the user, or to the teams he or she belongs to. The respective context (especially Business Unit) of these various roles is crucial.

How should you configure your user rights?

There are several ways, but you mainly have two options to configure the rights of users in Dynamics 365:

  • With security roles that are directly assigned to them.
    …and that apply in the context of the user’s Business Unit.
  • With security roles that are assigned to teams they belong to.
    …and that apply in the context of the team’s Business Unit.

It is of course possible (and sometimes necessary) to mix and match the two options, with both roles that are directly assigned to the user and others that are assigned to teams he or she belongs to:

Team or User security role

How to know the context of a security role?

Well, that’s an easy one: it’s written on it when you assign it!
A security role’s access level is only defined by the context of the user or team to which it is assigned:
Security Role and Context

Why should you assign at least one security role directly to a user instead of relying solely on team-based security?

It is recommended that even with a security model based on roles that are assigned to teams, users should have at least one security role directly assigned to them. It is mandatory if you want your users to be able to access personal CRM options, formats, languages, or have default forms, personal views, personal charts and personal dashboards (because they would need to be the owner of them, as it can’t be a team).

Base security role

You should also know that if you want users to be owner of records that only them should see, a security role containing a “read” privilege with a “user” access level, assigned to a team the user belongs to would not work. That would mean that the team can be the owner of the record, not the user belonging to the team.

Yes, security roles are additive… but be careful, they are additive in their respective context!

Security roles apply exclusively in the context of the user or team they are assigned to (and so in the context of the Business Unit of the user or team)


 Security Roles Cumulation
It is a misconception to think that because a user is part of a team, they can benefit from the team’s security role in their own user context. In fact, they benefit from each security role, but in their respective contexts.
Security Roles Accumulation
Stay tuned for more hands-on examples!

Basic (but important) considerations about the Dynamics 365 security model

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.

Concerning the User Interface, security lets you adapt a number of items for users:
  • Forms
  • Dashboards
  • 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)
On top of that, security also allows to define access to specific features, such as Excel Export, Printing, the use of the App for Outlook…

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.

CRM Crossing Paths Dynamics 365

 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.

Here’s an example of the impact of a JavaScript injected into a CRM form, that completely reveals and unlocks it:

CRM JavaScript Injection EN

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

By injecting this JavaScript code in a form, a user can display all hidden tabs, sections and fields, make editable all read-only fields, and remove any requirements for mandatory fields.

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).

javascript: var form = $("iframe").filter(function () {
    return $(this).css("visibility") == "visible"
try {
    form.Mscrm.InlineEditDataService.get_dataService().validateAndFireSaveEvents = function () {
        return new Mscrm.SaveResponse(5, "")
} catch (e) { }
var attrs = form.Xrm.Page.data.entity.attributes.get();
for (var i in attrs) {
var contrs = form.Xrm.Page.ui.controls.get();
for (var i in contrs) {
    try {
    } catch (e) { }
var tabs = form.Xrm.Page.ui.tabs.get();
for (var i in tabs) {
    var sects = tabs[i].sections.get();
    for (var i in sects) {
Another option is to install and use Sonoma Partners’ Dynamics CRM DevTools inthe Google Chrome extensions store:
Sonoma Partners Dynamics CRM DevTools

Golden Rules to design a security model in Dynamics 365

I’m starting a new series of articles dedicated to security modeling in Dynamics 365 Customer Engagement.

The aim is to go beyond the basic principles that are already detailed in Customization and Configuration courses or on TechNet.
I will provide design tips, best practice and examples to simplify a CRM security model implementation and administration.

Dynamics 365 Security

Why is it crucial to address the security model early in a project?

  • The Dynamics 365 Customer Engagement security model is powerful and flexible: it offers many options that can be combined.
  • It must be addressed right from the start of your project, because chances are it will impact your data model and business rules.
  • You must always have in mind your security model, in particular when you design business processes or complex data models (e.g. business processes encompassing several entities, or entities with child records…)

Security model design Golden Rules

  • Have the future in mind: think about the administration effort when you will have to configure hundreds of users.
  • Keep it simple: at some point, new people will have to understand it and make it evolve.
  • Don’t sweep things under the carpet: it might be tempting to not address a potential security issue, but it’s best to spend time on it while you are designing your model rather than wait for users to notice it in production.
  • Negotiate: opinions can change on how strict or complex the security model should be!
  • Share: educate your customer on how the standard security model works and what different options it offers, it will then be easier to try to fit in.
  • Differentiate: are we talking about filtering what we see, or restricting access to data? Sometimes a filtered view is just what you need.
  • Scalability and performance: your model might work well for a few users, business units and records. How would it scale for hundreds of thousands / millions?

The different security model options and how you should address them

Dynamics 365 Security Options_EN