Share approvals

When a builder says “share this with my team”, the platform records a pending request. Nothing changes until someone with the Ops role decides.

Review and decide

node plugin/lib/ops.mjs pending
# → req-id  app=incident-monitor  group=Sales Team  owner=<oid>  requested=<ts>

node plugin/lib/ops.mjs approve --id <requestId> --owner <ownerOid>
node plugin/lib/ops.mjs reject  --id <requestId> --owner <ownerOid>

(Ops can equally run this through Claude with the sprig plugin — “show pending sprig share requests” — or call the platform API directly.)

Approve assigns the Entra group to the app’s registration: group members can now open the app. Reject leaves the app owner-only. Both decisions are audit-logged with the deciding identity.

What you are deciding — and what you aren’t

You are deciding whether this app should be in front of that team. You are not deciding data access: every viewer’s queries run under their own identity, so approval can never expose data beyond what each viewer’s existing Fabric permissions allow. That containment is what makes a lightweight approval safe.

Practical guidance

• Approvals are per app + group; re-publishing an app does not reset its sharing.
• Prefer sharing to existing, well-owned Entra groups over creating app-specific ones.
• The pending queue is also visible at GET /api/share-requests for wiring into your own tooling or notifications.