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

Leave a Reply

Specify Facebook App ID and Secret in Super Socializer > Social Login section in admin panel for Facebook Login to work

Specify LinkedIn Client ID and Secret in Super Socializer > Social Login section in admin panel for LinkedIn Login to work

Specify GooglePlus Client ID and Secret in Super Socializer > Social Login section in admin panel for GooglePlus Login to work