Implemented-security-mechanisms

  • 5 minutes

In this section, you identify what methods are used to automate security, including automated sharing, field-level security, hierarchy security, plug-ins, and relationship behaviors. Refer to the security tools section of this module if you're unfamiliar with any of these approaches.

Reasons for providing this information:

  • Performance issues can occur if you automate sharing at scale. The PrincipalObjectAccess or POA table is filled with exceptions to the standard security model.

  • Sharing should typically remain a manual process to grant exceptions to the security model that is in place and should be avoided at scale.

  • While it's easy to adjust a user's business unit, teams, and roles, it can be complex to do a data migration on custom sharing rules after a reorganization.

  • Field-level security isn't user or business unit aware.

  • Hierarchy security can cause performance issues in complex configurations if too many levels are in the depth of the hierarchy.

  • Cascading behavior in relationships is convenient, but it can sometimes have unintended consequences (such as reassigning closed activities when an account is reassigned). Cascading assignment or sharing can be disabled or modified on a relationship basis, or by using an ORG DB setting of DisableImplicitSharingOfCommunicationActivities.

User interface

Many components of Dynamics 365 are security role enabled, meaning that access to that item can be limited to one or more security roles. This feature is important because different users require different experiences while using common tables, and by limiting access to app components that aren't needed by users, you will provide a simpler, more tailored experience for the user.

Items in Dynamics 365 that can be role-enabled include:

  • Model-driven apps

  • Dashboards

  • Forms

  • Business process flows

  • Site map subareas

  • Command bar buttons

  • Document templates

In this section of the template, you will identify if roles are being used to simplify access to these areas.

Reasons for providing this information:

  • Security roles and table privileges can be used to tailor and trim the experience for your users.

  • The fewer elements that users see, the easier the experience will be.

  • Model-driven apps can be associated with security roles and help simplify the overall user experience by trimming the list of views, charts, dashboards, forms, and business process flows.

  • Customers without a strategy in this area might experience unexpected issues. For example, the common Microsoft apps like Sales Hub, Customer Service Hub, and App for Outlook will control access by using app access security roles. If a customer tests with only a system administrator role, they might miss the fact that users without this role need the app access role to use the app (or the app needs to be shared with their custom security roles). This scenario can lead to users not having access to the apps that they need during deployment.