Monthly Archives: December 2021

Matrix data access structure

If one says “A”, he has to say “B”, right? So here is an addition to my yesterday’s “introduction to Microsoft Dataverse security model”. Hope you’ll find it useful, too.

In the basic security model, every user belongs to a business unit, and, when a role is assigned to a user, all permissions are applied in the context of the business unit which the user belongs to. Mind you, there are 4 levels of depth there, but two of them are business-unit specific (BU and parent-child BU), so I really mean those two.

Also, if a record is assigned to a user, it is automatically associated with the business unit which the owner belongs to (with the exception of organization-owned tables).

A usual problem in this scenario is giving users from different business units access to the data in other business units without exposing all of the organization data:

On the screenshot above, there is a role that gives full access to the account records in the business unit. However, since User 1 and User 2 belong to different business units, and since “Account Record” is assigned to User 1, how could User 2 see that record?

We can’t, always (if ever), use a hierarchy model to cover such scenarios, since relationships between User 1 and User 2 might be more complicated than those in the manager / position hierarchy. There are a few other options.We could:

  • Create a team, put it in Business Unit A, grant permissions to that team, and put User 2 in that team. That way, User 2 will inherit team permissions in the Business Unit A. That’s great EXCEPT that, when User 2 creates a new account record, that record will end up in Business Unit B this time. So it’ll be User 1 who won’t be able to see that new account records this time around. Which means we may have to create another team in Unit B, put User 1 in that team, give permissions to the team… but what’s the point of having two different business units, then, if we are, essentially, merging the business units?
  • Another option might be to rely on sharing. It could be direct sharing, or it could be sharing through the access teams, but, in either case, it’ll be all about explicitly sharing data owned by one user with the other users. This requires a lot of micromanagement, since (in the worst case) that kind of sharing may have to happen to every record in the above example

Matrix data access structure takes care of this problem on two levels. First of all, we can give  our users security roles directly in the business units:

Even though User 2 still belongs to Business Unit B, that user has been given a security role in Business Unit A this time around. And, just like that, the user now has access to all account records in Business Unit A.

Also, if User 2 creates another account record, that record does not have to be associated to Business Unit B. “Owning Business Unit” field has been decoupled from the owning user in the matrix model, so that hypothetical account record can stay in the Business Unit A even though it’ll be assigned to the User 2. Notice how on the diagram below our “account record” is assigned to User 2, but it still belongs to the Business Unit A. Which means User 1 can still access it:

Which may still require some automation to set it all up properly (to keep records in the proper BU using an automated process, for example), but the possibilities are there.


Note: this is an excerpt from the learning materials for the “Power Platform Learning course” course. There is definitely more to say on this topicSmile

Microsoft Dataverse security model intro

Not sure this overview of the security model in Microsoft Dataverse offers better/additional insight, but I came up with it anyways while working on the Power Platform course, so, hopefully, it’ll be useful.

In Microsoft Dataverse, security model operates with the following concepts:

  • There is a Dataverse Environment – it has its own database, its own users, its own security roles, teams, business units, etc
  • There are business units. Those are logical partitions where you can put users, teams, and child business units
  • There is one root business unit in each environment – it does not have a parent BU. Other than the “root”, there can be any number of child business units (each of the “child” business units has to have a “parent”)
  • Every business unit can have multiple teams. Every team can belong to only one business unit. There is a single default team per business unit. Users can be added to teams (teams cannot be added to other teams)
  • Every user in the specific dataverse environment has to belong to one and only one business unit
  • Security roles are not business unit specific – they belong to the environment, and they are assigned to the users/teams to grant access to data. Team security roles can be inherited by the users who are members of those teams
  • Column security profiles are no business unit specific – they belong to the environment, and users/teams can be added to the column security profile to grant granular access to data
  • Data records are not business unit specific – they belong either to the environment or to one of the “assignable” objects (a team or a user)

Dataverse will always ensure no user is able to access data they are not granted access to:

Dataverse will validate user access permissions in the context of the data action being requested. Access permissions in Dataverse are cumulative – permissions given through different roles & teams will be aggregated to perform the check above. Also, there are a few different types of access that may be given / requested, and data ownership has something to do with that as well.

Ignoring the column security profiles, since they are meant to secure individual columns, Dataverse will be looking at who owns the data, who it is shared with, and which business unit it belongs to when performing the access check:

And, of course, it will be looking at the permissions given to the user through the security roles assigned to that user directly, or through the security roles assigned to the user through team membership.

As far as possible “actions” go, there are 8 possible “actions” that can be secured in Dataverse per table:

  • Create
  • Read
  • Write
  • Delete
  • Append
  • Append To
  • Assign
  • Share

 

Except for the Append and Append To, the other ones are sort of self-explanatory.

Append “action” is all about adding a record to the N side of the relationship. For example,when  a contact is being added to an account through a 1:N relationship between accounts and contacts, that’s exactly appending contact to the account.

And that’s a separate permission that needs to be granted to the users through the security roles.

On the other hand, there can be a security role that’s giving “append” permission on a lot of different tables. Does it mean a user who has been given that role can append records in all those tables to any other table?

Actually, it’s a bit more advanced.

That same user needs to be given another permission, which is “Append To”, to append records from other tables to a specified table.

In other words, in that example with contacts being appended to the account, a user doing that has to have two permissions:

  • Append (on the contact table. To be able to append contact records to other tables)
  • Append To (on the account table. To be able to append to the account table)

Here is how security role configuration might look in the user interface:

There is, also, an agenda there, which explains what each circle means.

A “quarter” circle means that the permissions are given on the records assigned to the users.

A half-circle stands for the business unit.

A green “3 quarters” circle means business unit and child business units. Which is often called “parent-child business units”.

Finally, full green circle stands for the whole organization.

Default Dataverse behavior when a record is assigned to a user is to make user’s business unit the owning business unit for that record.

So, for example, if User A were to be assigned Contact 1, and if User B were in a different business unit, User B would need permissions to span across business units somehow to be able to access Contact 1. One option might be to grant User B access in the whole organization, of course. However, if User B’s business unit were a parent BU for User A’s business unit, then “Parent-Child” might also work. And so on.

And this is why this kind of security model is also called “owner-based” security. Do you remember how, when creating a table, you can specify table “Ownership” type, by the way?

This affects security in the following way:

  • For the organization ownership, there will be no user/team owners. Records in such tables are owned by the organization, so permissions cannot be controlled at the owner / BU level. It’s either all or nothing
  • For the user/team ownership, there is always a user/team owner. Which means permissions can also be controlled at the owner / BU level. Although, “all” permissions (in the whole organization) can still be granted

It does not end here, though. There are additional twists to this core model where we need to talk about hierarchy security, matrix data access, access teams, and more. And we’ll talk about it, just later.

What is Microsoft Dataverse?

I have been working on the Power Platform course lately, and a lot of “going back to basics” has been happening along the way.

One of the topics which seem to be surprisingly difficult to cover is explaining what Microsoft Dataverse is.

Here is how Power Platform docs describe Dataverse:
https://docs.microsoft.com/en-us/powerapps/maker/data-platform/data-platform-intro

“Dataverse lets you securely store and manage data that’s used by business applications. Data within Dataverse is stored within a set of tables. A table is a set of rows (formerly referred to as records) and columns (formerly referred to as fields/attributes). Each column in the table is designed to store a certain type of data, for example, name, age, salary, and so on. Dataverse includes a base set of standard tables that cover typical scenarios, but you can also create custom tables specific to your organization and populate them with data by using Power Query. App makers can then use Power Apps to build rich applications that use this data.”

In reality, this description does not seem to speak for what Dataverse is, since, if you replace Dataverse with “SQL Database” above, the whole paragraph is still going to sound just right.

There are some additional bullet points provided in the docs:

  • Easy to manage – Both the metadata and data are stored in the cloud. You don’t need to worry about the details of how they’re stored.
  • Easy to secure – Data is securely stored so that users can see it only if you grant them access. Role-based security allows you to control access to tables for different users within your organization.
  • Access your Dynamics 365 Data – Data from your Dynamics 365 applications is also stored within Dataverse, allowing you to quickly build apps that use your Dynamics 365 data and extend your apps with Power Apps.
  • Rich metadata – Data types and relationships are used directly within Power Apps.
  • Logic and validation – Define calculated columns, business rules, workflows, and business process flows to ensure data quality and drive business processes.
  • Productivity tools – Tables are available within the add-ins for Microsoft Excel to increase productivity and ensure data accessibility.

However, a lot of that can be said about other tools, too. For example, SQL server is relatively easy to manage, it offers security, there is metadata, there can be logic and validation, there are tools… so what makes Dataverse different?

I wonder if it would be a huge exaggeration to say that there are, actually, three concepts which make Dataverse unique in that sense:

  • Model-driven applications
  • Common data model
  • First-party applications

Essentially, it’s like this: first party applications (Dynamics 365 etc) are driving adoption of Dataverse, since they do require Dataverse. Common data model, which comes with those apps, allows for other apps to be created that can benefit from that core data and processes (yet some elements come with just any Dataverse environment). The easiest way to build advanced custom applications on top of Dataverse is by using model-driven apps. And, while building those model-driven apps, we need to keep using Dataverse and to keep pushing the limits more and more.

So, in a way, Dataverse is what glues those 3 concepts above together. The more we use any of those, the more we need Dataverse. Not that it’s good or bad, it’s just how things are, and it might not be that obvious at all if we try comparing Dataverse with SQL database without taking into account model-driven apps, common data model, and / or first-party apps provided by Microsoft.

Power Platform training course

This blog always used to be about my own experiences with Power Platform. Day after day, month after month, year after year… It used to be Dynamics, now it’s Power Platform. It used to be XRM, then CDS, then Microsoft Dataverse. It used to be classic workflows, now it’s Power Automate. And it’s still plugins.

The technology is changing, the tricks are changing, but learning never stops.

With that thinking in mind, for those interested in a more formal training, there is a Power Platform Learning Course now:

Part I of this course will focus on the non-code (or low-code) aspects of the Power Platform. Along the way, we will create a sample solution which will have a Canvas App front-end and a Model-Driven App backend. We will try a few different connectors and look at some of the other ones, yet there will be related deep-dive discussions on such topics as Dataverse security, Maker and Admin portals, Sharepoint and Email integration, and more.

Here is the list of modules covered in Part I:

  • The power to shoot for the sky
  • Setting up your training environment
  • Creating a simple quiz canvas app
  • Maker and Admin portals, including DLP
  • Canvas Apps deep dive by example: Quizzly Admin (work in progress)
  • Dataverse
  • Model-Driven Apps: Quizzly Admin in Dataverse (work in progress)
  • Model-Driven Apps: core out of the box functionality (Applications, Advanced Find, search, views, dashboards, reports, timelines, activities, email signatures)
  • Canvas App Exercise: Re-configuring Quizzly to use Dataverse connector
  • Dataverse security
  • Power Automate Cloud Flows
  • Application Lifecycle Management in the Power Platform
  • Sharepoint, Email Integration, App for Outlook
  • Word Templates, Email Templates
  • Licensing essentials

And there are a few add-on modules which are certainly needed for those aiming to pass Power Platform certification exams, but, depending on the pace of each group, these few modules might be left for self-learning instead:

  • Going public: portal-based Quizzly
  • Getting analytical: Power BI
  • Virtual Agents Chatbots
  • Desktop flows
  • AI basics

In the second part, which I am still working on, we will talk about development aspects of the Power Platform (plugins, PCF, in-depth Devops discussion, etc)

The goal is not, necessarily, to get course attendees certified in PL-200/PL-400. However, it is somewhat geared towards taking those two exams, so the idea is to equip everyone taking the course with enough knowledge to pass the exams anyways.

Each part will be delivered on Teams (could be done in-person, but, probably, not until the pandemic is over). It’ll be done in a group setting – there must be at least 4-5 participants, it’s a 5 days commitment, with at least 6-7 hours of learning per day.

The fee (per each part) is $1400 USD per attendee.

As an option, you might go for a guided self-paced training. The fee is going to be $1700 USD, and this is where you will be provided with the course materials and/or references to the Microsoft documentation which covers specific topics, yet you will have access to 15 hours of instructor time. Those hours will have to be consumes within a month of the start date, they will be billed in 1-hour intervals, and exact meetings schedule will need to be discussed before you start. This may work best in those cases where you cannot commit to 5 days in a row, and/or where you would prefer to spread learning over a few weeks for some other reasons. 

Corporate trainings are possible, please reach out to discuss if you are interested.

Want to know more and/or want to enroll? Feel free to reach out

PS. Do you want to test your Power Platform knowledge? Here are a few quick tests for you: