Data Platforms

What's on this screen

The Data Platforms panel is where a Vibedata Owner registers platform backends that Domains can use. Fabric entries include operator-level credentials for user-to-machine and machine-to-machine access.

How to add a Fabric platform

1. Open Org Settings and select Data Platforms.
2. Click Add platform or the add action for a new platform.
3. Choose Fabric when prompted for the platform type.
4. Fill in Name.
5. Fill in Fabric tenant ID.
6. Optionally fill in Fabric default capacity ID.
7. In hosted deployments, fill in U2M client ID and U2M client secret.
8. Fill in M2M client ID and M2M client secret.
9. Click Create Platform. Vibedata tests M2M first when configured, then opens Microsoft Entra for the U2M authorization.
10. Complete the popup. Vibedata saves only after every applicable lane passes.

How to use a platform with a Domain

1. Open Domains from the global application rail.
2. Create or edit a Domain.
3. Select the registered data platform in the Domain's platform or destination section.
4. Save the Domain.

Fabric capacities and workspaces in Domain creation and Resources are loaded with the current user's delegated connection. If the connection is absent, the page shows Connect in User Settings → Data Platforms. If it has expired, it shows Reconnect in User Settings → Data Platforms. Select that action, complete the Fabric sign-in under User Settings, and return to the Domain. Vibedata does not request capacities or workspaces while the connection state is loading or unusable.

A Fabric connection or resource request returning 401 means that provider connection needs repair; it does not mean the Vibedata login expired. Vibedata keeps you in Domains and must not enter a repeating /login redirect. If the whole Vibedata session has expired, the application-wide auth status—not a Fabric API response—owns sign-in recovery.

Grant the CI service principal access in Fabric

A Fabric Domain's CI runs as the Domain's CI service principal. Signing in does not give it any Fabric access; these three grants do. The sign-in itself is set up separately, see Set up GitHub OIDC trust for Fabric.

Grant	Purpose	Without it
Tenant setting Service principals can use Fabric APIs	Fabric rejects every service principal REST call until an admin enables the setting for a security group that contains the service principal.	Every Fabric call is refused, even after a successful login
Capacity admin	CI creates one workspace per pull request and assigns it to the capacity, which needs capacity admin. Azure RBAC Contributor alone is not enough.	Workspace provisioning fails
A role on the production workspace	Ephemeral lakehouses read production tables through shortcuts, so the service principal needs read access to the production workspace.	Shortcut seeding fails

T=$(az account get-access-token --resource https://api.fabric.microsoft.com --query accessToken -o tsv)

# 1. Tenant setting (caller must be a Fabric administrator). Read it first and use its settingName.
curl -s -H "Authorization: Bearer $T" https://api.fabric.microsoft.com/v1/admin/tenantsettings \
  | jq '.tenantSettings[] | select(.title|test("Service principals can use Fabric APIs"))'

curl -s -X POST -H "Authorization: Bearer $T" -H "Content-Type: application/json" \
  "https://api.fabric.microsoft.com/v1/admin/tenantsettings/<settingName>/update" \
  -d '{"enabled": true, "enabledSecurityGroups": [{"graphId": "<security-group-object-id>", "name": "<security-group-name>"}]}'

# 2. Capacity admin. This replaces the whole list, so include the existing admins.
az resource update \
  --ids /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Fabric/capacities/<capacity-name> \
  --set 'properties.administration.members=["<existing-admin-upn>","<sp-object-id>"]'

# 3. Production workspace role (caller must be an Admin of that workspace).
curl -s -X POST -H "Authorization: Bearer $T" -H "Content-Type: application/json" \
  https://api.fabric.microsoft.com/v1/workspaces/<prod-workspace-id>/roleAssignments \
  -d '{"principal": {"id": "<sp-object-id>", "type": "ServicePrincipal"}, "role": "Contributor"}'

Use the service principal's object ID, not its application (client) ID, in the capacity and workspace calls.

What you'll see

• Credential summary — Fabric rows show whether U2M and M2M client slots are saved.
• Validation results — shows U2M and M2M as separate passed, failed, or skipped lanes.
• Archived — archived platform rows are kept but are not used for new work.
• Error — missing Fabric credentials are reported as configuration work for Org Settings → Data Platforms.

Quick reference

Control	What it does
Name	Sets the display name for the platform row.
Fabric tenant ID	Identifies the Fabric tenant.
Fabric default capacity ID	Provides the default Fabric capacity for new workspaces.
U2M client ID / U2M client secret	Configures user-to-machine Fabric OAuth.
M2M client ID / M2M client secret	Configures machine-to-machine Fabric operations such as Branch-Out and Key Vault access.
Create Platform	Validates the exact draft, opens Entra when U2M applies, and saves only on success.

If the popup is blocked, denied, closed, or expires, the existing platform is unchanged. Correct the reported lane and choose Retry. Changing a tenant, client, secret, or other credential-bearing value clears any earlier result and requires a new validation. A name-only edit does not require the interactive flow.

Related

• Org Settings
• Domains
• GitHub