Modernized Business Units - perhaps finishing off something that was always meant to be!

You might have seen the announcement about Modernized Business Units in Microsoft Dataverse.

I made a video on it as well to show you the opportunities that it opens up when designing Microsoft Dataverse security models for both model-driven and canvas apps.

In summary, the change can be broken down into two parts:

1. You can now assign a Security Role from a business unit outside of the user's own business unit - this allows users to access records in different business units as though they were a member of that business unit. This could replace more traditional approaches that might have previously involved sharing and/or team membership.
2. Records can now have an owning business unit that is different from the business unit of the Owning Users/Team. This means that when users move between business units, there are potentially fewer scenarios where you need to re-assign ownership of those records, and the user can maintain access to their records without complex workarounds.

Check out my video and the official docs for more info.

Whilst I was exploring this new feature it occurred to me that this was perhaps the way that the Security Role assignment and Owning Business Unit was always meant to work from the start. Here are my reasons:

1. The owningbusinessunit field has always been there in table definitions - but shrouded in mystery!
   1. It was automatically updated by the platform to match the business unit of the owning user or team.
   2. You couldn't add this field to forms.
   3. You couldn't always use it in view search criteria because it was set to being non-searchable for some entities - but enabled for others.
   4. There was always mystery surrounding this field since there were limitations to its use - but if you wrote a plugin, you could set it inside the plugin pipeline to a value different to the owning user/team's business unit - but with unknown consequences!
   5. Alex Shlega even wrote a blog post about this mysterious field a few years ago.
2. Security Roles have always been business unit specific:
   1. If you have ever had to programmatically add a Security Role to a user - you'll have had to first find the specific Security Role for the user's Business Unit since each Security Role created is copied for every single business unit - with a unique id for each.
   2. When moving a user between Business Units, their Security Roles were removed, because they were specific to the old business unit (This is now changing with this new feature thankfully!)
   3. I can't be 100% certain - but I have some dim-and-distant memory that when using a beta version of CRM 4.0 or maybe CRM 2011, there was the option to select the business unit of a Security Role when editing it - as it is today you can't do this and receive the message 'Inherited roles cannot be updated or modified :
      
      Now that would introduce some interesting scenarios where you could vary the privileges of the same role inside different business units.

Maybe I dreamt that last point - but it certainly seems that whoever originally designed the data model for Business Units and Security Role assignment wanted to allow for users to have roles assigned from different business units - or at least supporting varying role privileges across different business units. Or maybe, it was a happy coincidence that the data model already supported this new feature!
I wonder if there is anyone who worked on the original code who can comment!

@ScottDurow