Teams & members

Sankofa's people surface is two-tiered: members belong to the organization, and teams are named groups of members that can be assigned project access in bulk. The split mirrors how real teams work — you have one HR-style org membership, and you slot people into one or more squads that own a project surface.

Members

A member is an authenticated user with at least one role somewhere in the organization. Members are managed at /dashboard/account/members.

Invite a member

1. Click Invite member

   Email + initial organization role (Owner / Admin / Member). The "Member" org role is the most common — it grants no project access by default; you grant per-project roles separately.

2. They accept the invite

   The invitee receives an email with a sign-up link. After accepting, they appear in the members list with their assigned role.

3. Assign project access

   Click their name → Project access → assign a role per project (Viewer / Editor / Admin), or assign them to a team that already has project access. See RBAC for the role matrix.

Member roles at the organization level

Organization Owners and Admins automatically have project Admin rights on every project — there's no need to assign them per-project.

Removing a member

Removing a member from the organization revokes their access everywhere. Their authored content (tickets, flags, configs, comments) is preserved but attributed to a "Deleted user" placeholder. To remove someone:

/dashboard/account/members → click their name → Remove from organization.

For SSO + SCIM-managed orgs, deactivate the user in your IdP — the SCIM job propagates the change to Sankofa within minutes.

Teams

A team is a named group of members that share project access. Teams exist for two reasons:

1. Bulk project assignment. Add five engineers to the iOS team once; granting the team Editor on a new mobile project means all five inherit Editor without per-member invites.
2. 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.

Manage teams

/dashboard/account/teams shows every team in the organization. Each team has:

• Name + description — how it's labeled in the dashboard.
• Members — explicit list. Members can be in multiple teams.
• Project assignments — each entry is (project, role). The role applies to every team member on that project.
• Default role for new projects — used when you bulk-assign the team to a new project.

Create a team

1. Click New team

   Name + description. Pick the team's default project role (Viewer / Editor / Admin).

2. Add members

   Pick from the organization's member list.

3. Assign projects

   Click "Add project access" → pick a project + role. The team's role on that project applies to every team member.

Override a team member's role

If you have a team that's mostly Editors but one member needs Admin on a specific project:

1. Open the project

   /dashboard/<project>/settings/access.

2. Find the member

   The team grants them Editor by default; you'll see "via <team name>".

3. Override per-member

   Click the role dropdown → pick Admin. The override beats the team default.

To remove the override and revert to the team default, delete the member-level entry.

SSO-managed organizations

When SSO is enabled (Enterprise), members provision automatically:

• JIT (Just-in-Time) — first sign-in creates the member with the default org role (configurable in the SSO settings).
• SCIM 2.0 (optional) — members + teams sync from your IdP. Adding a user to your IdP's iOS group adds them to the corresponding Sankofa iOS team. The members page becomes read-only.

For the full setup, see SSO & SCIM.

API surface

The dashboard members + teams pages back onto these endpoints. Use them for CI scripts, custom admin tooling, or webhook-driven member sync.

For SCIM-managed orgs, mutations via these endpoints are blocked (the IdP is the source of truth). See SSO & SCIM.

What's next