Account model
RBAC and teams
Viewer, Editor, Admin, Owner — what each role can do, how teams scope access, and how RBAC works under SSO.
Role-based access control on Sankofa is intentionally simple: four roles per project, with a single Owner role at the organization level. Teams group people together so you can assign a project to a team in one click instead of inviting each member separately.
The four project roles
Every member that has access to a project holds exactly one of these roles. Roles are project-scoped — a member can be Viewer on one project and Editor on another, in the same organization.
ViewerroleEditorroleAdminroleOwnerrolePermission matrix
| Action | Viewer | Editor | Admin | Owner |
|---|---|---|---|---|
| View events / dashboards | ✓ | ✓ | ✓ | ✓ |
| Run queries / build cohorts | ✓ | ✓ | ✓ | ✓ |
| Watch session replays | ✓ | ✓ | ✓ | ✓ |
| Read flags / configs / surveys | ✓ | ✓ | ✓ | ✓ |
| Create / edit flags + configs | ✓ | ✓ | ✓ | |
| Halt a flag (incl. via webhook) | ✓ | ✓ | ✓ | |
| Create / publish deploys | ✓ | ✓ | ✓ | |
| Manage cohorts and dashboards | ✓ | ✓ | ✓ | |
| Manage project members | ✓ | ✓ | ||
| Rotate API keys | ✓ | ✓ | ||
| Configure integrations | ✓ | ✓ | ||
| Export audit log | ✓ | ✓ | ||
| Manage billing + plan | ✓ | |||
| Manage SSO / SCIM | ✓ | |||
| Set data-residency region | ✓ | |||
| Delete project | ✓ |
Owner is the only role at the organization level; the other three are project-scoped.
Teams
A team is a named group of organization members. Teams have two purposes:
Bulk project assignment
Add a member to the
iOSteam, and they automatically inherit access to every project theiOSteam has been granted access to. When you spin up a new mobile project and want the same crew on it, you assign the team — no per-member invites.Default role per team
A team has a default role (e.g.
iOS team → Editor on Mobile project). Individual member overrides on specific projects still work — the team default is just the starting point.
Teams are managed from Account → Teams in the dashboard. They don't grant any access on their own — they're a convenience layer over project membership.
SSO and SCIM
For organizations on the Enterprise plan:
- SSO (SAML 2.0) — every login goes through your IdP. We support Okta, Azure AD / Entra ID, Google Workspace, and any generic SAML 2.0 provider. Just-in-time provisioning is supported when paired with SCIM. See SSO setup.
- SCIM 2.0 — SCIM-managed organizations push membership and team assignments from the IdP. Adding a user to the
iOSgroup in your IdP automatically adds them to theiOSteam in Sankofa with the team's default role.
When SCIM is on, the dashboard's Account → Members page becomes read-only — the IdP is the source of truth. To remove a member, deactivate them in the IdP.
Audit log
Every action that changes user-visible behavior is logged: flag toggles, config publishes, deploy promotions, key rotations, member adds / removes, and access-grant changes. The audit log is visible to Admins and Owners and can be exported to CSV or streamed to a SIEM via webhook (Pro tier and above). See Audit log.
What Sankofa does NOT do
- Granular per-flag access. A project Editor can edit any flag in the project. If you need finer separation, split into multiple projects.
- Time-boxed access. Roles are persistent — there's no built-in "grant access for 24 hours then auto-revoke." Build that on top of the Members API if you need it.
- Field-level redaction in the dashboard. A Viewer sees the same event payload as an Editor. If you need to hide PII from some viewers, redact at ingest with allow/deny lists. See Events.