What it does

The matrix data access structure lets a user work across several business units at once. Data stays compartmentalised in the business unit tree, but a user can hold roles from multiple business units and own rows in any of them. It's controlled by the Record ownership across business units switch on the environment.

Key facts

• Turn it on at Settings > Product > Features in the Power Platform admin center. The underlying setting is EnableOwnershipAcrossBusinessUnits, also settable through OrgDBOrgSettings.
• Publish all customisations before enabling, so unpublished tables are included. If tables were missed, RecomputeOwnershipAcrossBusinessUnits set to true allows the Owning Business Unit column to be set and updated.
• With it on, you choose a business unit when assigning a security role to a user, so one user can carry roles from several business units.
• The user also needs a role from their own business unit carrying user settings privileges in order to run model-driven apps. The Basic User role is the reference for which privileges those are.
• A user can own rows in any business unit provided they hold a role — from anywhere — with Read privilege on that table. They don't need a role in each owning business unit.
• The Owning Business Unit column becomes settable. To let users set it, grant the role Append To on the Business Unit table at local level, and surface the column on the form (body and header), views, or column mappings.
• AlwaysMoveRecordToOwnerBusinessUnit defaults to true. Set it to false so rows stay in their original owning business unit when ownership changes. Production environments that ran this during the preview period also need RecomputeOwnershipAcrossBusinessUnits set to true; non-production only needs the AlwaysMove setting.
• Setting RecomputeOwnershipAcrossBusinessUnits locks the system for up to five minutes while it recomputes.
• Turning the feature back off resets every row whose Owning Business Unit differs from the owner's business unit back to the owner's business unit, and you lose the ability to set the column.
• It also relaxes hierarchy security: ManagersMustBeInSameOrParentBusinessUnitAsReports can be set to false so managers can have reports in other business units.

When to use / skip

This is the answer to the shared-services problem — one support desk, one finance team, one set of specialists serving multiple divisions that must otherwise stay separate. Under the classic hierarchical model that either means duplicate users, a flat structure that abandons the separation, or organisation-level access to everything. The matrix model solves it properly. Skip it if a single business unit tree already fits how people work, because you're adding configuration, a settable ownership column and a set of database settings that all need documenting. And don't enable it speculatively on a live environment: switching it off is not a clean reversal.

Configuration decisions

• Whether AlwaysMoveRecordToOwnerBusinessUnit stays true or goes false, which decides whether reassigning a row also relocates it in the security tree.
• Whether DoNotRemoveRolesOnChangeBusinessUnit is flipped so moving a user keeps their existing roles.
• Whether users may set Owning Business Unit themselves, which needs Append To on the Business Unit table plus form and view changes.
• Which users get roles from more than one business unit, and how that's recorded so it's reviewable.
• Whether to pair it with Entra security groups mapped one-to-one with business units, which is Microsoft's recommended pattern for getting users into the right access set.

Gotchas

• Turning the feature off is destructive to your ownership data. Every row where Owning Business Unit differs from the owner's business unit is rewritten. There's no undo.
• Sync jobs break. If Owning Business Unit is in the schema and the target environment doesn't have a matching business unit, the job fails with a foreign key constraint violation. You either drop the column from the source schema or align the values.
• Exports to external destinations such as Power BI need Owning Business Unit deliberately selected or deselected depending on whether the target can accept it.
• Users can run model-driven apps only if they hold a role in their own business unit with the user settings privileges. Assign roles from other business units only and the apps won't open, which looks like a licensing fault.
• Changing which business unit owns a row triggers relationship cascade behaviour. Reassigning ownership across the tree can move a lot more than the row you touched.
• Environments that ran this during the preview period need extra steps that a fresh environment doesn't. Worth checking the history of any environment you inherit.

Consultant notes

• Enable it in a sandbox and exercise the full lifecycle — assign, reassign, move users, run the integrations — before it goes anywhere near production. The switch is easy; the consequences are not.
• Treat the OrgDBOrgSettings values as configuration-as-documentation. They change core behaviour, they're invisible in the admin UI, and the next consultant will have no idea they were set.
• Pair it with the Entra security group per business unit pattern from the start. It's the difference between this being elegant and this being a manual role-assignment burden.
• Warn integration owners specifically about Owning Business Unit appearing in schemas. It's the failure that turns up two weeks after go-live in a nightly job nobody was watching.

---

Worth checking again as guidance around modernised business units settles, and if the feature switch ever becomes safely reversible.