Dataflow Gen2 authentication to Lakehouse without user dependency?

Hi,

We have run into a challenge with Dataflow Gen2 in Microsoft Fabric.

When creating a dataflow and selecting a destination, for example a Lakehouse in the same workspace, the authentication appears to require an Organizational account. In practice, this means that the connection becomes tied to a specific user.

This creates governance and operational challenges in larger organizations. If the user who created or authenticated the dataflow leaves the company, changes role, or loses access, someone else needs to take over the dataflow and re-authenticate the connection. In an organization with thousands of users, this quickly becomes difficult to manage and track.

I understand that in some scenarios it may be possible to use a service principal, but that raises another question: how many service principals should be created and maintained? Should it be one per workspace, per domain, per team, per solution, or something else?

For this specific scenario, Workspace identity feels like a much more natural fit. A workspace-scoped identity would reduce the dependency on individual user accounts and make the solution more robust over time.

Microsoft’s documentation describes Workspace identity as a Fabric-managed service principal associated with a workspace, where Fabric manages the credentials and can use the identity with resources that support Microsoft Entra authentication. The Lakehouse connector documentation also shows that, for Dataflow Gen2, the supported authentication type is currently Organizational account.

My questions are:

• What is the recommended best practice for authenticating Dataflow Gen2 when writing to a Lakehouse in the same workspace, without creating a dependency on a personal user account?
• Is using a service principal the recommended approach today?
• If so, what is the recommended pattern: one service principal per workspace, per team, per solution, or something else?
• Are there any plans to support Workspace identity for this scenario?

It would be very helpful to hear how other organizations are handling this, especially in larger environments where ownership changes and user lifecycle management can otherwise become quite difficult.

Thanks in advance!