Dataverse row-level security for Entra ID B2B guest users

A distributor needs to see the opportunities they are working with you on. A contractor needs to update the work orders assigned to their crew. A large customer wants their own project manager in your project system. Each of these people is outside your organisation, and the tempting shortcut is to invite them as an Entra ID B2B guest and give them a Dynamics 365 licence. It can work well. It can also become the audit finding of the year, because guests inherit the same Dataverse security model as employees, and that model only restricts what you tell it to.

What a B2B guest is in Dataverse terms

An Entra B2B guest is an external identity, from another Entra tenant or a consumer account, invited into your tenant. Once invited, the guest can be assigned a Dynamics 365 or Power Apps licence and added to a Dataverse environment like any user. Inside Dataverse there is no such thing as a "guest": they are a system user with security roles, a business unit, and team memberships, and they see exactly what those grant. The word "guest" is an Entra concept, not a Dataverse one.

That is the point to internalise. If a guest is given the standard Salesperson role, they see every account and opportunity the role grants, across the whole business unit. Nothing about being external limits them.

Building the fence

Row-level security for guests comes from the same three tools as for anyone else, used deliberately.

A dedicated business unit per external organisation. Create a business unit for each partner or customer that gets guests, place the guests in it, and give them roles whose read and write privileges are set to Business Unit depth, not Organization. They then see only rows owned by users or teams in their business unit. This is the coarsest and most reliable fence, and it is the one to start with. See hierarchical security for how depth works.

Ownership by a team in that business unit. Rows the guests should see must be owned by, or shared with, something in their business unit. The usual pattern is an owner team per partner; when an opportunity is assigned to that partner, the owner is set to the team, and the guests see it. Rows owned by your employees in the root business unit are invisible to the guest, which is what you want. See owner teams vs access teams.

Access teams for row-by-row sharing. When a guest should see one specific record without owning it (a project they are staffed on, a case they are consulted on), an access team template on the table lets you add them to that row alone. This is finer-grained and more work to administer; use it for exceptions, not for the bulk of access.

Then close the side doors. Guests should have no privileges on tables they do not need, including the ones the standard roles grant liberally: notes, activities, connections, and the system tables that leak names. Column-level security hides fields such as margins and internal notes; see field-level security. And check the app: a model-driven app shared with the guest shows every table in its sitemap that the role permits, so build a separate, minimal app for external users.

Conditional access and device posture

Guests arrive from devices and networks you do not manage. Entra conditional access policies can require multifactor authentication for guests, restrict them to browser access, block downloads, or require the partner's tenant to satisfy cross-tenant trust settings. Apply a guest-specific policy; the employee policy assumptions do not hold. Our guide on Dynamics 365 and conditional access covers the mechanics.

Licensing

A guest using a model-driven Dynamics 365 app needs the same licence an employee would for that app. There is no guest discount. For a handful of partner managers that is fine. For hundreds of contractor field technicians it is not, and the licence bill becomes the argument for a portal instead.

When guests are the wrong tool

Guests suit a small number of trusted, named external users who need the full app experience and will be trained on it. They do not suit large populations, anonymous or self-registering users, or anyone whose access must be scoped to their own data by design rather than by administration.

For those, the alternatives are Power Pages with Entra External ID or B2C authentication, where table permissions scope access to the signed-in contact's own rows and the licensing is per authenticated user or per capacity, or a custom application in front of the Dataverse API with its own authorisation. See Entra External ID for customer access for the identity side. The rule of thumb: named partners inside the app, populations through a portal.

What breaks in practice

Guests placed in the root business unit "for now". Standard roles copied and assigned without trimming. Records reassigned from a partner team to an employee, which removes the partner's visibility with no warning. Guests whose home tenant deprovisions them but who remain licensed and enabled in yours; tie guest lifecycle to a review process. Reports and Power BI dashboards shared to guests that bypass Dataverse security entirely.

Stability verdict

The security model itself is stable and does exactly what it is configured to. The instability is administrative: every new partner needs a business unit, a team, a role check, and an app share, and the first time someone skips a step a guest sees too much. Automate the onboarding with a flow or a script, review guest access quarterly, and keep the population small. For the model behind all of this, read the Dataverse security model.