Does Link to Microsoft Fabric behave differently from Azure Synapse Link here?

The exposure is the same in the sense that matters: neither carries F&SCM extensible data security into the destination. Link to Fabric keeps the managed copy inside the Dataverse governance boundary and grants Fabric users authorised read access, but once a user has that access, the rows are not filtered by ERP policy. The control is workspace and OneLake security either way.

Can I re-create extensible data security policies in Fabric?

You can re-create the effect, not the policy. The rules have to be expressed again in whatever the destination understands: OneLake security, workspace roles, or row-level security in a Power BI semantic model. There is no import path that reads the ERP policies and applies them.

Is there a way to export only the rows a role can see?

Not through these services. They replicate tables. If a subset is genuinely all that should exist outside the ERP, the filtering has to happen after landing, with access to the unfiltered copy restricted to the pipeline identity rather than to people.

Does field-level security carry?

No. Restricted columns arrive as columns. If a field is sensitive enough to be restricted inside Dynamics 365, treat it as needing an explicit decision on the way into the lake.

Name one person before the first sync. In practice it works best when the ERP security owner writes the specification, because they are the only one who knows what is filtered today, and the Fabric workspace owner implements and maintains it.

Does Row-Level Security Carry Into Microsoft Fabric?

No. It does not carry, and this is the single most expensive assumption people make when they connect Dynamics 365 to an analytics platform. Extensible data security policies are bypassed for the Synapse Link service. The rows arrive in the lake without the security model that governed them inside the ERP, and nothing in the setup flow tells you that has happened.

The practical effect: a person with access to the lakehouse sees every legal entity, every cost price, and every restricted field in an HR table, regardless of what Finance and Supply Chain Management would have shown them.

What the export actually moves

It moves tables. Not entities, and not the security that sat in front of them.

Inside F&SCM, what a user can see is the result of several layers working together: the legal entities their role is scoped to, extensible data security policies that filter rows by a query, and field-level restrictions on sensitive columns. Those layers live in the application. They are evaluated when the application serves a request.

The export path is not the application serving a request. It is a service reading tables, and it reads them whole.

Why almost nobody notices in time

Three reasons, and they compound.

The setup flow does not mention it. Connecting Link to Microsoft Fabric is a short sequence of prerequisites and permissions. Nothing in it asks what your data security policies are or warns that they will not travel.

The people doing the connecting are administrators. A System Administrator in the Power Platform environment is the role required to set this up. That person sees everything in the ERP already, so the lakehouse looks correct to the only person positioned to spot that it is not.

The first consumer is usually a report, not a person. The data lands, a semantic model is provisioned, a dashboard gets built, and it all works. The exposure is real from the first sync, but nothing surfaces it until somebody with narrower ERP access is given workspace access and finds they can now answer questions they could not answer yesterday.

What is actually exposed

Anything the ERP was filtering. The common ones:

Every legal entity. Role scoping to a subset of companies does not survive the export. A user restricted to one operating company reads all of them.
Cost prices and margin. Frequently restricted inside the ERP for sales-facing roles, and unrestricted in the lake.
HR tables. Compensation, personal details and employment records, where those tables are in scope.
Anything protected by a data security policy rather than by a role, since the policy is exactly the layer being bypassed.

What governs it inside Dynamics 365	What governs it in the lakehouse
Legal entity scoping on the user's role	Nothing. All companies are present in the table
Extensible data security policies (row filters)	Nothing. The policy is bypassed for the Synapse Link service
Field-level restrictions on sensitive columns	Nothing. Restricted columns arrive as ordinary columns
Application-evaluated permission checks per request	Workspace role and OneLake security, defined separately
Power BI report-level filters, if any	Row-level security in the semantic model, defined separately

Where the control plane moves to

Security does not disappear. It relocates, and it has to be rebuilt deliberately in the new place.

For a Fabric lakehouse, the controls are OneLake security and workspace roles. For Power BI on top, row-level security is defined in the semantic model. Neither is derived from Dynamics 365. Someone has to state the rules again, in the new system's terms, and keep them in step as the ERP's own roles change.

That last part is the ongoing cost people forget to plan for. The ERP security model is not static: legal entities get added, roles get adjusted, a new policy gets written. Every one of those changes has a shadow in the lake that will not update itself.

What to do before you connect anything

Decide the audience first. Not "who needs reporting" but "who will hold workspace access, and what is the most sensitive row they could reach through it".

Inventory what is filtered today. List the extensible data security policies in force and the fields restricted for each role. That list is the specification for the lakehouse access model. Without it, you are rebuilding a security model from memory.

Separate workspaces by sensitivity. It is easier to keep finance and HR out of a workspace than to filter them inside one, and a workspace boundary is far harder to misconfigure than a row filter.

Decide whether every table needs to go. F&O tables you can choose. Non-system Dataverse tables with change tracking enabled are selected automatically and cannot be removed, because Dynamics and partner apps depend on them, so the scope is partly yours and partly decided for you. Knowing which is which tells you where filtering is even an option.

Write down who owns it. The ERP security owner and the Fabric workspace owner are usually different people in different teams. If neither believes the lake access model is theirs, it will drift.

The wider point

This is a specific instance of a general rule worth carrying into any data platform decision: security is a property of the system that enforces it, not a property of the data. Move the data, and you have moved it out from behind the enforcement.

That is not an argument against the lake. Link to Microsoft Fabric and Azure Synapse Link are the two current, supported paths, and the reasons to use them are good. It is an argument for treating the access model as part of the build rather than something to sort out once the reports are working, because by then people already have access.

Key takeaways

Row-level security does not carry from Dynamics 365 into Fabric or Synapse Link: extensible data security policies are bypassed for the Synapse Link service.

Lakehouse access can expose every legal entity, cost prices and restricted HR fields regardless of the user's ERP permissions.

The control plane moves to OneLake security, workspace roles and Power BI semantic-model security, and each has to be defined from scratch.

The people who configure the link are administrators who already see everything, which is why the gap is rarely spotted at setup.

The ERP security model keeps changing after go-live, and none of those changes propagate to the lake automatically.

Common mistakes to avoid

Assuming the export inherits ERP permissions because the connection was made by an ERP administrator.

Granting workspace access before the lakehouse access model exists, on the basis that the data is "just reporting".

Rebuilding security only in Power BI, which leaves anyone with direct lakehouse or SQL endpoint access outside the control.

Treating the access model as a one-off task rather than something that has to track changes to ERP roles and legal entities.

Putting finance, HR and operations data in one workspace and planning to filter it per user.

Does row-level security carry from Dynamics 365 into Fabric?