Dynamics 365 Security Model: Business Units, Teams and Who Sees Whose Records

Should you use business units or teams to control who sees whose records?

Start from the requirement, not the feature list. Most organisations that ask this question want one of a small number of things, and each has a mechanism that fits it. Business units are the heaviest tool in the model: every user belongs to exactly one, every security role is scoped through one, and moving people between them has side effects. That is why the default answer is owner-based security with hierarchy security, and why business units are reserved for data that genuinely has to be partitioned.

The rule we apply when designing or reviewing a model is below. Where the table says "business unit", read it as a decision that needs a written reason, because it is the choice that is hardest to undo later.

How does owner-based security with the manager hierarchy work?

Every user- or team-owned record carries an owner and an owning business unit. A security role then grants each privilege (create, read, write, delete, append, append to, assign, share) at a depth: User, Business Unit, Parent: Child Business Units or Organization. A rep with User-level read on opportunities sees the opportunities they own, plus anything shared with them and records owned by a team whose security role grants its members that access. That is the whole of "reps see their own".

Hierarchy security adds "managers see their team's" without widening the role. Once hierarchy modelling is enabled and the tables are included, a manager gets access to records owned by the people below them, to the depth you configure. There are two models, and choosing the wrong one is a common cause of managers who suddenly see nothing.

• Manager hierarchy uses the Manager field on the user record. A direct manager gets read, write, append and append to on records owned by their direct reports; managers higher up the chain get read-only access. The manager must be in the same business unit as the report or in its parent business unit.
• Position hierarchy uses positions you define and assign to users, independent of the manager field and of business units, so it works for managers whose teams sit in other business units.
• Hierarchy security never grants a privilege the manager does not have at all: the manager still needs at least User-level privileges on the table in their own role.
• Keep the depth deliberate. A deep hierarchy on a large organisation gives senior managers read access to a great deal of data, which is sometimes the intent and sometimes an audit finding.
• Maintain the manager field or positions as part of the joiner, mover and leaver process, because hierarchy security is only as accurate as that data.

When do business units genuinely make sense for separate branches or entities?

Business units are the right answer when data must not mix: branches that are separate legal entities, a regulated subsidiary whose auditors need to see that another entity cannot read its customers, or franchise-style units that share a platform but not a customer base. With business unit-level privileges, users see records owned within their business unit, and Parent: Child depth lets a head office see the branches below it.

They are the wrong answer when they are used to mirror the org chart. Every department as a business unit means every reorganisation becomes a security change, users who move lose their roles, and people who need to collaborate across units end up with direct shares that nobody tracks.

The classic model forced a user and their records into a single business unit. Modernized business units, enabled with the record ownership across business units setting, remove that constraint: a user can hold security roles assigned in other business units, and a record can have an owning business unit that is different from its owner's. That is the matrix data access structure, and it is usually a better fit than adding teams in every unit just to let a regional manager see two branches. Turn it on deliberately and test it in a sandbox, because it changes how access is calculated for everyone.

Which team type do you need: owner team, access team or Microsoft Entra group team?

Teams are where most models become hard to explain, because three different things share one name. Choose by what the team has to do.

How do column security and export privileges fit into the security model?

Record access answers who can open a row. Column security answers who can see a value inside it. Enable column security on the sensitive columns and grant read, create and update through column security profiles assigned to users or teams. Users without a profile see the column as secured, and the platform enforces it across forms, views and the API. System Administrators have full access to secured columns, which is one more reason to keep that role to very few people.

Export needs a realistic view. The Export to Excel privilege in the security role controls the command in the application, but anyone with read access and API access can still retrieve what they can read. The defensible control is therefore read access itself, backed by who holds roles with Organization-level read, who holds the System Administrator and System Customizer roles, and who can create connections or apps against the environment.

How do you produce a defensible list of who can see and export what today?

Before changing anything, write down the model as it actually is, not as it was designed. Auditors, and the person who has to sign off the change, need the same artefact: a register they can read without opening the admin centre. If you want an independent party to produce it as part of a wider assessment, the Dynamics 365 health check and technical audit covers security posture alongside the rest of the environment, so it is not repeated here.

• Roles by user: every enabled user, their business unit, the roles assigned directly and through each team, and the resulting depth on the tables that hold customer, financial and personal data.
• Broad access: everyone with Organization-level read on sensitive tables, System Administrator, System Customizer, and export or bulk privileges.
• Teams: owner, access and Entra group teams, their members, their roles, and who manages membership.
• Sharing: the volume of direct shares by table and by recipient, and which ones cascade.
• Hierarchy: whether manager or position hierarchy is enabled, the depth, the included tables, and users with an empty or stale manager.
• Column security: secured columns and the profiles and members that can read them.
• Change evidence: Dataverse auditing enabled for role assignment and ownership changes. On individual records, the free Easy Audit PCF control makes owner and value changes readable when someone asks who moved a record and when.

How do you change a live security model without losing record visibility?

This is where environments get broken. The usual failure is a sequence problem: a user is moved to a new business unit and loses their roles, a team is deleted before its records are reassigned, or broad access is removed on Friday before the new access has been tested. Changing a user's business unit removes their security roles by default, and records they own follow them unless modernized business unit settings say otherwise, so check those environment settings before the first move.

The order below is the one we use. Its two principles are that access is added before it is removed, and that every ownership change is logged well enough to be reversed without restoring the whole environment. A full environment restore is the last resort, because it also discards every legitimate change made since the backup.

• 1. Freeze security changes in production and take a manual environment backup, so the only changes during the work are the planned ones.
• 2. Record a visibility baseline: for each persona, a named real user and the count of records they can see in the key tables and views, plus the rows they must not see.
• 3. Export the current security roles, team memberships, business unit structure and hierarchy settings into a solution or a written register, so the old model can be put back.
• 4. Rehearse the whole change in a sandbox copy of production, including ownership reassignment, and compare the rehearsal results against the baseline.
• 5. Add first: create the new teams, roles, positions or business units and grant the new access while the old access is still in place, so nobody loses a record mid-change.
• 6. Reassign ownership in batches by business area, logging every record with its previous owner and owning business unit, and check the cascade behaviour of each relationship before the first batch.
• 7. Retest each persona with the real users after every batch, against the baseline, before starting the next one.
• 8. Remove the old access last: Organization-level privileges nobody should hold, direct shares that the new model replaces, and retired teams.
• 9. Keep the ownership log and the exported old model until the business has worked a full cycle, such as a month end, on the new model.

What should you test before and after each security change?

Test with real users in each persona, never with an administrator account, because an administrator sees everything and proves nothing. Where a user cannot join a session, impersonation through the API can confirm what a given user can retrieve, but the sign-off should still come from the people who do the work.

What should you do with business units inherited from a merger or a previous partner?

Inherited structures are the most common reason a model is hard to explain: business units that mirror a company that no longer exists, a unit per department from an early design, or teams created to work around a partition that was never needed. Do not delete or flatten them first. Map what each unit actually partitions today, which records it owns and which roles depend on it, then decide unit by unit whether it still reflects a real boundary.

Where it does not, move users and records into the target structure using the change order above, reassign team-owned records before retiring the team, and disable a unit only once it owns nothing and nobody depends on it. Where two companies are also consolidating two CRMs, the data side is covered in our guide to post-merger CRM consolidation. If Copilot or AI agents are being introduced over the same data, fix the security model first, because they answer from what the user can read; see governing Copilot over Dynamics 365 data.

Who can redesign the security model if there are no local Dynamics 365 specialists?

Solzet designs, audits and remediates Dynamics 365 Customer Engagement and Power Platform security models remotely from Yerevan, Armenia, for organisations in the UK, Germany, the Netherlands, the US and Armenia, as a fixed-scope engagement: the register of current access, the target model, the sandbox rehearsal, the batched change and the tests with your users. Organisations in Armenia and the region without local specialists can read how we work there on our Dynamics 365 partner in Armenia page. If the environment is broken beyond the security model, the project rescue and takeover service is the better starting point.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. If per-user licensing, hosting or a requirement for complete control over the data model rules out Dataverse, a custom CRM on React, Node.js, PostgreSQL or .NET can implement the same partitioning, with the access rules engineered explicitly rather than configured.