Skip to content

Offboarding a member

When someone leaves, removing them from your identity provider is not enough, and neither is removing their AppGantry membership on its own. Credentials in AppGantry belong to different owners — some to the person, some to the project, some to the organization — so they have to be cleared separately.

Work down this list in order. The first step has to happen before you remove the membership: an organization's last Admin cannot be removed, demoted, or allowed to leave, so a removal attempted out of order simply fails. After that, the fastest-acting steps come first.

What deprovisioning in your IdP actually does

Removing someone in your identity provider stops them signing in via SSO. It does not remove their AppGantry membership, end an existing session, or revoke a personal access token, a project access token, or any other credential they hold. Treat it as one step, not the whole job.

1. Make sure another Admin remains

Admin is ownership in AppGantry — there is no separate owner — so "hand ownership over" and "leave an Admin behind" are one step, not two. Promote a remaining member to Admin before you remove the departing one, using the Ownership tab or an ordinary role change. Both grant the role and leave your own untouched.

Do it first. An organization with no Admin cannot be administered: nobody can reach billing, storage configuration, SSO, spend caps, or the audit feed. The API will not let you get there — the last Admin cannot be removed, demoted, or allowed to leave — so skipping this step does not orphan the organization, it blocks the removal you came to do. It is also what unblocks account deletion for a sole administrator.

See Ownership and Roles.

2. Remove the membership

Remove the person from every organization they belong to. This is the step that actually withdraws authorization: role checks run per request, so a removed member stops being able to act on the organization even if they still hold a valid session cookie.

Removing a member does not delete the things they created — builds, channels, testers, and project access tokens all belong to the project or organization, not to the person.

See Organizations & members.

3. End their sessions

Membership removal doesn't sign anyone out. A departing member's browser sessions and access tokens stay valid for their remaining lifetime, and they can still act on anything else they have a membership for.

A developer can revoke their own sessions from Account settings. If the person is cooperative, ask them to sign out everywhere; if they are not, and you need a hard cut-off, contact support.

See MFA, passkeys & sessions.

4. Revoke their personal access tokens

A personal access token acts as the person. It is owned by the developer, and each one is bound to a single organization.

Removing the membership withdraws that token's authorization for your organization — it stops being able to act there. What it does not do is delete the token: the object survives, it stays listed for its owner, and any tokens they hold in other organizations are entirely unaffected. Membership removal is not a global kill switch for a credential.

Clear them properly from both ends:

  • The developer revokes their own PATs from Account settings. Ask them to, and treat the request as part of the handover.

  • An organization Admin can enumerate and revoke every PAT in the organization over the API. There is no screen for this in the web app today, so drive it yourself:

    Operation Route
    List every PAT in the organization GET /api/v1/pats/all?organization_id={organization_id}
    Revoke one of them DELETE /api/v1/pats/{pat_id}?organization_id={organization_id}

    Both require organization Admin, and both are token-management operations, so they need an interactive sign-in — a personal or project access token is refused on them whatever its scope. Request and response shapes are in the interactive API reference.

Revoking is the durable answer; removing the membership is only the organization-scoped one.

See Authentication and Feature availability.

5. Rotate project access tokens they could have read

A project access token belongs to the project, not to the person who minted it. Removing a member leaves every project token they created — or simply saw — fully live.

Assume any token value the departing member had access to is compromised: mint a replacement, update the CI secret that uses it, and revoke the old one.

See CI with project access tokens.

6. Rotate shared credentials they had access to

Anything the organization holds as a shared secret needs the same treatment if the person could read or configure it:

  • Webhook signing secrets. Rotate the secret on each subscription they could see. See Webhooks.
  • Store connections. Apple and Google credentials are stored sealed and are never shown back, but a departing member may hold the original credential at the provider. Rotate it there and re-create the connection. See Store connections & publishing.
  • SDK app secrets. These ship inside your binary and are deliberately low-authority, so they don't normally need rotating on departure — but re-check that assumption if you've used one for anything else.
  • BYOSA storage access. If the person administered your Azure tenant, review the role assignment on the container. See BYOSA setup.

7. Remove them from your identity provider

Now close the SSO route. Doing it at this point rather than first means you still had a working account to audit and hand over from.

See SSO.

8. Hand over the rest of what they owned

The Admin role, which is also ownership, is dealt with above. What's left is everything attached to the person outside AppGantry:

  • Store and IdP accounts held in the person's name at the provider.
  • CI pipelines that authenticate with a credential you just revoked.

9. Check the audit trail

Read the audit feed for the period around the departure. It records membership changes, token creation and revocation, sign-ins, and settings changes, so it is the fastest way to find a credential you forgot about.

See Audit events.

Quick checklist

Step Who can do it Survives if you skip it
Promote another Admin, which is how ownership is handed on Organization Admin A removal the API refuses, and nobody able to administer the organization
Remove membership Organization Admin Full role-based access
End sessions The developer, or support A live browser session
Revoke personal access tokens The developer, or an organization Admin over the API A surviving token that still acts for them in their other organizations
Rotate project access tokens Organization Admin A CI token they know the value of
Rotate webhook secrets Organization Admin The ability to forge deliveries
Rotate store credentials Organization Admin, at the provider Publishing rights
Remove from the IdP Your IdP administrator Future SSO sign-in

See also