Forum Discussion
Best practice validation — SP profile-based, no-human-access workspace design for embed-only client
Hi all,
I'm building a multi-tenant embedding setup (Embed for your customers) and want to sanity-check the architecture before I lock it in at scale. Looking for validation or pushback from anyone who's run this in production.
Setup:
- One dedicated Power BI workspace per client (e.g. [ClientName]_Embed), all assigned to a shared Embedded/Fabric capacity.
- A single master service principal (app registration) for the embedding application.
- One service principal profile per client, created under that master SP.
- Each client's profile is the only identity with a role (Member/Admin) on that client's workspace.
- No individual human users are ever added to these workspaces — access is entirely programmatic via the SP profile generating embed tokens.
- A small, tightly audited break-glass Azure AD security group has temporary Admin access for emergencies only.
- Tenant settings: "Publish to web" disabled, external sharing disabled on these workspaces, "Allow service principals to use Power BI APIs" scoped to a security group containing only the SP.
Questions:
- Is there a real, practical benefit to SP profiles over just using the master SP directly on each workspace, once you're past the ~1,000-workspace soft limit consideration — or does profile-per-client add meaningful isolation even at smaller scale (say, 10–50 clients)?
- Are there any known limitations/gotchas with SP profiles I should watch for — e.g. around dataset refresh history, activity log attribution, or dataflow ownership — that don't show up until you're running this in production?
- Is Member sufficient for the profile's role, or are there embed scenarios (RLS management, dataset takeover, XMLA read/write) that actually require Admin?
- For anyone running a similar "zero human access" workspace model — has this caused friction with support/troubleshooting in practice, and how do you handle it besides the break-glass group?
- Anything about this design you'd flag as an anti-pattern or would do differently at scale?
Appreciate any real-world experience here — happy to share more detail if useful.
Hi Divyaraj_Rathod ,your design is broadly sound and is very close to Microsoft’s recommended multi-tenant embedding pattern. The main thing I’d push back on is how much extra isolation you get from profiles versus a plain master SP—it’s useful, but not a magic security boundary. The bigger wins are operational scale, cleaner tenant separation, and avoiding the 1,000-workspace ceiling.
My take on each question
1) Profile per client vs. master SP directly on each workspace
Practical benefit of profiles: yes, but mostly operational rather than security isolation.
What profiles buy you:
- Cleaner per-customer identity separation for token generation and API operations.
- A path to scale well past the single-SP workspace ceiling.
- Easier tenant lifecycle management if you automate everything.
- Better fit with Microsoft’s multi-tenant embedding guidance:
- “workspace-based isolation with profiles” is the recommended pattern in the docs.
What profiles do not really buy you:
- They are not a hard isolation boundary in the way separate Entra apps or separate capacities would be.
- If the master app is compromised, the attacker can still act through the app unless your surrounding controls are strong.
- For 10–50 clients, profile-per-client is more about keeping your architecture future-proof and your code/ops clean than about a dramatic security gain.
My recommendation:
If you already know this will scale, use profiles now. The overhead is small compared with retrofitting later. But don’t sell it internally as “stronger security” than it really is; it’s primarily multi-tenant operational isolation.2) Known limitations / gotchas with SP profiles
The ones I’d care about most in production:
a) Not all Power BI surfaces fully support service principals
Microsoft explicitly calls out that:
- service principals can’t sign in to the portal
- My Workspace isn’t supported
- dataflow management is not fully supported
- some read-only APIs need extra tenant settings
That means your “zero human access” model is fine for the embedding app, but if your solution depends on dataflows heavily, plan for gaps.
b) Dataflows are the biggest “looks fine in dev, hurts in prod” area
If you use dataflows, watch for:
- ownership behavior
- refresh/connection re-authentication issues
- limitations around service principal support for management actions
If dataflows are central, I’d be cautious and test the exact lifecycle you expect: create, edit, refresh, ownership transfer, credential rotation.
c) Activity log attribution can be less intuitive
Your audit trail will often show the app/profile identity, not a human. That’s good for machine governance, but it means:
- troubleshooting requires strong internal correlation IDs and app logs
- support teams can’t rely on “who clicked what” in the portal
d) Refresh history is finite
Refresh history retention is limited, so don’t treat Power BI’s native refresh history as your long-term system of record. Export/retain refresh telemetry elsewhere if it matters.
e) XMLA and external tools change the operating model
If you enable XMLA read/write and use external tooling:
- you can lose the ability to download PBIX in some cases
- you should expect more “database-like” ownership semantics
- some support paths become more technical
3) Is Member sufficient, or do you need Admin?
For most embedding scenarios, Member is usually sufficient if the profile needs to:
- publish/import content
- generate embed tokens
- manage items in the workspace
- handle standard report/dataset operations
When Admin becomes useful or necessary:
- workspace ownership recovery / takeover scenarios
- some lifecycle operations that are easier under admin
- certain dataset/model management tasks
- emergencies and break-glass support
- some XMLA / tabular admin-style workflows, depending on what you are doing
My practical rule:
- Default to Member
- Use Admin only where the automation really needs it
- Keep the break-glass path separate and tightly controlled
If you expect model-level admin work through XMLA or want to recover from broken ownership states, having an admin path available for the automation identity is often helpful, even if it’s not the default.
4) “Zero human access” model — does it create support pain?
Yes, it can, unless you compensate with good observability and a documented emergency path.
The friction usually shows up in:
- “Can someone just open the workspace and inspect it?” → not possible
- data issue triage requiring portal access that no human has
- ownership/credential issues that require a controlled admin action
- refresh failures where the root cause is easier to diagnose interactively than via logs
What works in practice:
- Break-glass group like you described
Good. Keep it time-bound and audited. - A separate operational support role
- maybe not workspace admin by default
- but with access to logs, refresh telemetry, and deployment status
- Strong app-level observability
- store tenant ID, workspace ID, dataset ID, report ID, profile ID
- log embed token requests and failures
- capture request correlation IDs
- Runbooks
- refresh failure
- token generation failure
- workspace corruption / ownership loss
- credential rotation
- A non-production “support clone” process
- same architecture, but isolated test tenant/workspace where support can reproduce issues without touching production
5) Anything I’d flag as an anti-pattern?
A few things to watch:
a) Don’t confuse profiles with security isolation
They help with multi-tenant identity management, but if you need strong tenant isolation, think in terms of:
- separate workspaces
- separate capacities if needed
- strict tenant-scoped authorization in your app
- separate keys/secrets/rotation policies
b) Be careful with dataflows as a core dependency
If the solution can work with datasets/semantic models and less dataflow complexity, that’s often easier to operate.
c) Don’t make the master SP too powerful
The shared SP is a high-value credential. Minimize:
- tenant settings scope
- workspace membership blast radius
- who can rotate secrets/certs
- who can deploy to production
d) Automate provisioning from day one
At 10 clients you can “get by” manually. At 100+ you’ll regret it. Automate:
- workspace creation
- profile assignment
- capacity assignment
- dataset/report deployment
- refresh config
- monitoring hookup
- teardown
e) Plan for supportability, not just correctness
A perfectly isolated architecture that nobody can debug becomes expensive fast.
3 Replies
Hi Divyaraj_Rathod ,your design is broadly sound and is very close to Microsoft’s recommended multi-tenant embedding pattern. The main thing I’d push back on is how much extra isolation you get from profiles versus a plain master SP—it’s useful, but not a magic security boundary. The bigger wins are operational scale, cleaner tenant separation, and avoiding the 1,000-workspace ceiling.
My take on each question
1) Profile per client vs. master SP directly on each workspace
Practical benefit of profiles: yes, but mostly operational rather than security isolation.
What profiles buy you:
- Cleaner per-customer identity separation for token generation and API operations.
- A path to scale well past the single-SP workspace ceiling.
- Easier tenant lifecycle management if you automate everything.
- Better fit with Microsoft’s multi-tenant embedding guidance:
- “workspace-based isolation with profiles” is the recommended pattern in the docs.
What profiles do not really buy you:
- They are not a hard isolation boundary in the way separate Entra apps or separate capacities would be.
- If the master app is compromised, the attacker can still act through the app unless your surrounding controls are strong.
- For 10–50 clients, profile-per-client is more about keeping your architecture future-proof and your code/ops clean than about a dramatic security gain.
My recommendation:
If you already know this will scale, use profiles now. The overhead is small compared with retrofitting later. But don’t sell it internally as “stronger security” than it really is; it’s primarily multi-tenant operational isolation.2) Known limitations / gotchas with SP profiles
The ones I’d care about most in production:
a) Not all Power BI surfaces fully support service principals
Microsoft explicitly calls out that:
- service principals can’t sign in to the portal
- My Workspace isn’t supported
- dataflow management is not fully supported
- some read-only APIs need extra tenant settings
That means your “zero human access” model is fine for the embedding app, but if your solution depends on dataflows heavily, plan for gaps.
b) Dataflows are the biggest “looks fine in dev, hurts in prod” area
If you use dataflows, watch for:
- ownership behavior
- refresh/connection re-authentication issues
- limitations around service principal support for management actions
If dataflows are central, I’d be cautious and test the exact lifecycle you expect: create, edit, refresh, ownership transfer, credential rotation.
c) Activity log attribution can be less intuitive
Your audit trail will often show the app/profile identity, not a human. That’s good for machine governance, but it means:
- troubleshooting requires strong internal correlation IDs and app logs
- support teams can’t rely on “who clicked what” in the portal
d) Refresh history is finite
Refresh history retention is limited, so don’t treat Power BI’s native refresh history as your long-term system of record. Export/retain refresh telemetry elsewhere if it matters.
e) XMLA and external tools change the operating model
If you enable XMLA read/write and use external tooling:
- you can lose the ability to download PBIX in some cases
- you should expect more “database-like” ownership semantics
- some support paths become more technical
3) Is Member sufficient, or do you need Admin?
For most embedding scenarios, Member is usually sufficient if the profile needs to:
- publish/import content
- generate embed tokens
- manage items in the workspace
- handle standard report/dataset operations
When Admin becomes useful or necessary:
- workspace ownership recovery / takeover scenarios
- some lifecycle operations that are easier under admin
- certain dataset/model management tasks
- emergencies and break-glass support
- some XMLA / tabular admin-style workflows, depending on what you are doing
My practical rule:
- Default to Member
- Use Admin only where the automation really needs it
- Keep the break-glass path separate and tightly controlled
If you expect model-level admin work through XMLA or want to recover from broken ownership states, having an admin path available for the automation identity is often helpful, even if it’s not the default.
4) “Zero human access” model — does it create support pain?
Yes, it can, unless you compensate with good observability and a documented emergency path.
The friction usually shows up in:
- “Can someone just open the workspace and inspect it?” → not possible
- data issue triage requiring portal access that no human has
- ownership/credential issues that require a controlled admin action
- refresh failures where the root cause is easier to diagnose interactively than via logs
What works in practice:
- Break-glass group like you described
Good. Keep it time-bound and audited. - A separate operational support role
- maybe not workspace admin by default
- but with access to logs, refresh telemetry, and deployment status
- Strong app-level observability
- store tenant ID, workspace ID, dataset ID, report ID, profile ID
- log embed token requests and failures
- capture request correlation IDs
- Runbooks
- refresh failure
- token generation failure
- workspace corruption / ownership loss
- credential rotation
- A non-production “support clone” process
- same architecture, but isolated test tenant/workspace where support can reproduce issues without touching production
5) Anything I’d flag as an anti-pattern?
A few things to watch:
a) Don’t confuse profiles with security isolation
They help with multi-tenant identity management, but if you need strong tenant isolation, think in terms of:
- separate workspaces
- separate capacities if needed
- strict tenant-scoped authorization in your app
- separate keys/secrets/rotation policies
b) Be careful with dataflows as a core dependency
If the solution can work with datasets/semantic models and less dataflow complexity, that’s often easier to operate.
c) Don’t make the master SP too powerful
The shared SP is a high-value credential. Minimize:
- tenant settings scope
- workspace membership blast radius
- who can rotate secrets/certs
- who can deploy to production
d) Automate provisioning from day one
At 10 clients you can “get by” manually. At 100+ you’ll regret it. Automate:
- workspace creation
- profile assignment
- capacity assignment
- dataset/report deployment
- refresh config
- monitoring hookup
- teardown
e) Plan for supportability, not just correctness
A perfectly isolated architecture that nobody can debug becomes expensive fast.
Keep one SP profile as Admin on each client workspace and use app‑owns‑data embed with that profile, and a simple way is to create the workspace, add the profile as Admin, call the REST API with the profile id, and keep a small audited break‑glass group outside.
Hi Divyaraj_Rathod ,
Thank you for reaching out to fabric community.
Could you please review the suggestions provided above and let us know if you have any further questions?
Thanks!!
