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.
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.
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!)
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
- 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.
|Entity||Owner||Business rule to identify the owner|
|Contact||Team||Depending on the contact’s country:
|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
|Note||User / Team||It depends: