Welcome to the sixth post in my series focused on providing a set of revision notes for the PL-400: Microsoft Power Platform Developer exam. Last time around, we deep dove into some of the core concepts to grasp around Microsoft Dataverse for the exam, including tables, columns and relationships. Today, we can now move onto the final topic within the Configure Common Data Service area of the exam and focus our attention on learning about the following:

Configure security to support development

• troubleshoot operational security issues
• create or update security roles and field-level security profiles
• configure business units and teams

One of the arguable benefits of leveraging the Power Platform and, in particular, Microsoft Dataverse (AKA the Common Data Service), is the fantastic security model afforded to us. Using this capability allows us to provide highly specialised access to our businesses data, based on an individuals role or position within an organisation. All of the tools above can help us achieve these objectives, and more, so let’s dive and find out more about how to use them within the platform.

As with all posts in this series, the aim is to provide a broad outline of the core areas to keep in mind when tackling the exam, linked to appropriate resources for more focused study. Ideally, your revision should involve a high degree of hands-on testing and familiarity working with the platform if you want to do well in this exam.

Note on Terminology

In late 2020, shortly before the PL-400 exam went into general availability, Microsoft made some significant changes to the core terminology in some areas of the Power Platform, chiefly affecting some of the concepts discussed in today’s post. I discussed these changes as part of a blog post last year, but, in a nutshell:

• Microsoft Dataverse was announced as the new name for what was previously known as the Common Data Service. This change was announced and discussed further by Ryan Cunningham in a blog post last year.
• Within Microsoft Dataverse, many of the core features were renamed. For example, entities are now called tables. Microsoft has provided an excellent summary table that you can use to refer to the previous and new terms.

At the time of writing this post, Microsoft has yet to update the PL-400 exam to reflect the new terminology. Therefore, you should take steps to familiarise yourself with the previous terms, so you won’t get stuck when sitting the exam. For this blog post, we will be referring to the new terminology throughout.

How Security Works in the Microsoft Dataverse

Microsoft Dataverse provides an incredible amount of features to help implement even the most stringent access requirements. As such, developers can leverage this existing functionality to help speed up development and focus on building a workable solution, rather than divert time/effort towards creating a sophisticated security model out of the box. At a high-level, the following features are made available to us from a security standpoint:

• Business Units: These act as hierarchical containers for your data, allowing you to restrict access to rows, based on a logical structure. Typically, this may be mapped based on an organisational structure or geographic locations within a global organisation. All user accounts must exist within a single business unit, and there is a requirement that all Dataverse environments have at least one root business unit. For further details on this topic, please refer to the following Microsoft Docs article.
• Security Roles: The cornerstone of security within the application, Security Roles provide users with the permissions needed to interact with Dataverse data. We’ll be taking a much closer look at this feature in the next section.
• Teams: Although typically used to sub-categorise users within a Business Unit, Teams can be assigned Security Roles, to help you simplify setting privileges in bulk. It is also possible to configure an Access Team template, allowing end-users to grant permissions to a row without any further customisation needed. Find out more about how to manage Teams with the following Microsoft Docs article. To find out more about access-teams and how to set them up, please consult this article instead.
• Column-Level Security Profiles: Sometimes, it may be necessary to not only restrict a whole table but the contents of a specific column. An excellent example of this involves credit card numbers. Although it is desirable to grant users the ability to enter this information on row creation, restricting access beyond this point would be highly beneficial. Field-level Security Profiles can help meet this requirement and will be discussed in more detail shortly.
• Row Sharing: All users within the application, provided they’ve been assigned the relevant Share privilege at a Security Role level, can grant temporary or indefinite access to rows. This feature can be useful for situations where someone is going away for a few weeks, and you need to provide limited access to a colleague covering this absence.

Developers have the flexibility to use one or several of these features when building out their solution. Typically, Security Roles will be the one area you divert your most attention to, particularly when creating new tables.

Discussing Security Roles

Users accessing Microsoft Dataverse, either via a model-driven app, Power BI or another mechanism, must be assigned a security role. The Security Role defines which tables, features and other components within the Dataverse the user can interact with. By default, all Dataverse instances come equipped with several out of the box roles, indicated below:

At the time of writing this post, although it’s possible to add Security Roles to a solution within the new Power Apps portal, creation and modification of them take place within the classic interface.

Security role permissions can be broke down into two broad categories - row-level and task-based privileges**.** Also, access level privileges will apply to specific tables. The bullet points below provide a general summary of each of these topics:

• Row-level Privileges: Available for all tables, regardless of their ownership type, these permissions define the specific access privileges that a user can achieve against a table. These, by and large, following a CRUD concept for persisted storage (Create, Read, Update and Delete). Specifically, the full list of privileges are:
  • Create: Allows the user to create new rows for this table.
  • Read: Allows you to read the row entirely, but make no changes.
  • Write: Allows you to modify existing rows of this table.
  • Delete: Let’s you delete the table row in question.
  • Append: Allows you to associate the table with another table row.
  • Append To: Allows other table rows to be related to this table row.
  • Assign: Allows you to re-assign the row to another user.
  • Share: Let’s you share the row with other users.
• Task-Based Privileges: These typically allow you to carry out specific, non-table bound actions within the application. For example, you can grant permissions for users to Create Quick Campaigns or Assign manager for a user.
• Access-level Privileges: Going back to Business Units, the Dataverse security model lets you define whether users can access rows within their Business Unit, in ones directly underneath them or across the entire organisation. These granular level privileges are only available if you have configured a table with an ownership type or User or Team. Tables with Organisational level privileges do not support this and, instead, it is necessary to grant all or zero permissions. The full list of levels available for selection within the application are:
  • Organization: Users allowed this level of access to a table have unrestricted access across the system, regardless of which business unit the row resides within.
  • Parent: Child Business Units: With this privilege level, users can interact with all rows of the table in their current Business Unit or any child Business unit, regardless of depth.
  • Business Units: At this level, users can only interact with rows in their current Business Unit. Depth access does not apply in this scenario. For example, if I’m granted Read Business Unit level privilege, I’d be unable to read any rows within a child, grandchild etc. business unit.
  • User: The most restrictive level, only rows which I own or shared with me will be accessible if granted this level.

Altogether, Security Roles provide a robust, granular and flexible approach to locking down areas of the application or ensuring that users only interact with rows they own, for example. To find out more about Security Roles, please refer to the following Microsoft Docs article. Security Roles is a massive topic in of itself, and impossible to cover in-depth as part of a single blog post.

Column-Level Security Profiles

We’ve already touched upon just what Column-Level Security profiles are, so let’s dive into some of the finer points of their functionality.

A system administrator/customiser must create a Column-Level Security Profile and, in most cases, you will want to include this as part of a solution. The 2-step setup process will involve:

1. Enabling the Column Security property: Developers must do this on every column that requires securing. There are no settings that need toggling at the table level first. Certain column types, such as the Primary Key column, are not supported for column security.
2. Update or create a new Column Security profile, defining your required privilege level: A profile will expose all columns enabled in the system for column security, for which you must then specify the following settings:
   • The users or teams that the profile applies to.
   • The actual permissions to grant to the users or teams assigned to the profile. The following permission types are available; it is possible to mix and match these privileges, to suit your requirements:
     • Read
     • Create
     • Update

To find out more about setting up column-level security and profiles, you can refer to the following Microsoft Docs article.

Troubleshooting security issues

Typically, the bane of any Power Platform administrators life will be in resolving access or security-related issues, which can be tricky to navigate and fall through the net during any UAT testing. The list below provides a flavour of things to watch out for with security features in the Dataverse:

• Review any generated error message carefully. These will almost always indicate the missing privilege and the affected table, thereby allowing you to modify any assigned security role accordingly.
• Where possible, try and base any security role off an existing, out of the box role and tailor it accordingly. There is a myriad of minimum privileges required to open a model-driven app in the first place, which can prove challenging to figure out when creating a security role from scratch.
• A column enabled for column security will only be visible to system administrators within the application if no similar column security profile has been set up and assigned. Consider the impact this may have when enabling this property for this first time.

Demo: Understanding Teams, Security Roles and Column Security Profiles in Microsoft Dataverse

To help gain a better grasp of the concepts discussed in this post, take a look at the video below, where I will show you how to work with Teams, Security Roles and Column Security Profiles:

Neglect the security capabilities within Microsoft Dataverse at your peril. They can often enable you to model out even the most complex access requirements, without ever needing to resort to a single line of code. Next time in the series, we’ll be moving onto the next focus area of the exam, as we take a look at how to build out a model-driven Power App.