D365 Customer Engagement (CE) Security Introduction
D365 Customer Engagement applications (formerly known as CRM applications) work together to intuitively manage the complicated web of customer relationship management. They are becoming an increasingly powerful asset as Microsoft continues to roll out new functionality and seamless integrations. Thus, there is a growing need to ensure that the sensitive data within the application is appropriately shared and secured. The platform provides a robust security architecture with a wide array of building blocks, but there’s just one problem: there isn’t much information available on how to combine these components to best meet an organization’s evolving needs!
In this blog, we will cover the foundational concepts of D365 CE security and explore options for creating a tailored security design. Stay tuned for a later post where we will dive further into the CE concept of teams and discuss how they can be leveraged to enhance security.
At its core, D365 CE utilizes two concepts to control access granted to users: organization-based and role-based security. These two concepts work in tandem to control what access each user has.
Background: Organization Hierarchy
By using organization-based security, CE has the power to divide an organization into business units (with optional parent-child relationships) and teams. Individual users are assigned to these organizational structures to limit what data or records they can access. There are a few key concepts critical to note:
- Individual users can only be assigned to one business unit
- A team can only be assigned to one Business Unit,
- Individual users can be assigned to multiple teams, thus a team can include users from the same or different business units
The following diagram illustrates the relationship between these structures. The arrows represent what is being assigned to the entity. For example, User 3 is being assigned to Team 2 (marked in orange) and Team 2 has users from each of the three child business units.
Background: Role-Based Security
In order to understand the possibilities created through teams, we must first understand the role-based security architecture. Pre-defined ‘out-of-the-box (OOB) roles come delivered with the application (e.g. Service Representative, Salesperson); however, most organizations will want to create custom roles (usually by copying an OOB role and adjusting it for the organization’s needs). A role is traditionally assigned to each individual user to limit exactly what he or she can see and do within the application. Three key concepts are used to define a role: entities, privileges, and access levels.
An entity is a data object that usually refers to a type of record, such as a contact. The eight record-level privileges – create, read, write, delete, append, append to, assign and share – determine the permissions a user has to a specific entity (such as contact).
The access level determines how deep or high in the organizational business unit hierarchy the user can perform each individual privilege. Represented by the colored circles on the security role configuration page, access level is defined at four different levels:
- Global (organization-wide)
- Deep (business unit and subordinate business units)
- Local (business unit)
- Basic (user or team).
View more information on these security concepts on Microsoft docs.
Background: Record Ownership
Traditionally, a specific user is the owner of a given record. The owner is typically the person who originally created that record; however, workflows can be configured to change record ownership based on the needs of the business. The “assign” privilege can also be used to designate a new owner. Access level determines the particular records to which a user has privileges. At the user level, the individual can access only his/her own records; at the local level, records owned by users within his/her business unit; at the deep level, records owned by users within his/her business unit and subordinate business units; and at the global level, to all organization records.
Microsoft Branding and Relevant Applications
Microsoft’s frequent re-branding might leave you wondering which applications use this security structure. This security structure is relevant for Microsoft’s suite of Dynamics 365 customer engagement applications, including sales, customer service, marketing, field service and project service automation. These applications can be deployed both online (cloud) and on-prem.
Learn more about Dynamics 365 applications and Customer Engagement (on-prem) on Microsoft documentation.
Conclusion
CE security has multiple structures to provide flexibility when granting access to users. With that flexibility comes complexity and it is critical to think about how to use each of these structures when architecting a security structure. We hope this blog provides an understanding of the key concepts used to design security roles for D365 CE tools.
To learn more about Protiviti’s Microsoft capabilities, please visit our Microsoft Solutions site or contact us.
