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

Ask Claude: “Anything waiting for me?” → list_share_requests shows the pending queue (request id, app, requested group, owner, requested-at). Then “Approve” / “Reject, wrong team” → approve_share / reject_share, naming the request id.

Approve adds the requested Entra group as a member of the app’s viewers group: group members can now open the app on their next visit, no deployment involved, a pure Graph call. Reject leaves the app owner-only (optionally with a reason shown back to the requester). 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. What that implies for data access depends on how the app’s sources are enforced, and the two cases are genuinely different.

For Azure SQL sources, every viewer’s queries run under their own identity, so approval cannot expose data beyond what each viewer’s existing permissions on the source database already allow. That containment is what makes a lightweight approval safe.

For Fabric Warehouse and lakehouse sources, it does not hold the same way. Those are read with sprig’s own service identity and filtered per viewer above the database, so approval is also a data-access decision: a viewer can see rows their own permissions on the warehouse would not have given them. Treat a share request for an app backed by a Fabric source as one, and check what the app exposes before approving. The source list shows which enforcement each source uses, and the console marks gateway-enforced sources with a badge.

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.
• To be told when a request arrives instead of checking, see Notifications.