Summary and recommendation
Snyk user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Snyk structures access across two scopes: the Group (top-level container) and individual Organizations within it. Every app in your stack that connects to Snyk does so at the org level, so access control decisions made here propagate directly to which projects, integrations, and reports each developer can reach.
The three built-in roles - Group Admin, Org Admin, and Org Collaborator - are available on all paid plans; custom roles require Enterprise.
Quick facts
| Admin console path | app.snyk.io → [Group name] → Members (group level) or app.snyk.io → [Org name] → Settings → Members (org level) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Group Admin | Full administrative control across all organizations in the group; can manage group settings, billing, SSO, members, and roles; can create and assign custom roles | Cannot act below group scope without also being an org member | Enterprise (Groups are an Enterprise feature) | Counts as a billable seat | Group Admin is the highest privilege level; assigning it broadly creates significant blast radius across all orgs in the group |
| Org Admin | Full control within a single organization: manage members, integrations, projects, and org settings | Cannot manage group-level settings, SSO configuration, or billing; cannot create custom roles | Free and above | Counts as a billable seat | Org Admin scope is limited to the specific org they are assigned to; must be added separately to each org they need to administer |
| Org Collaborator | Can view and test projects, view reports, and manage their own integrations within an org | Cannot manage org members, change org settings, or delete projects | Free and above | Counts as a billable seat | Default role assigned when a user is invited without a specific role specified |
| Custom Role | Configurable set of permissions chosen from Snyk's permission catalog at group or org scope | Cannot exceed the permissions of the Group Admin role; permissions are limited to those Snyk exposes in the permission catalog | Enterprise | Counts as a billable seat | Custom roles are defined at the group level and then assigned to users within orgs; requires Group Admin to create |
Permission model
- Model type: hybrid
- Description: Snyk uses predefined roles (Group Admin, Org Admin, Org Collaborator) available on all plans, plus custom roles available on Enterprise. Permissions are scoped to either the Group level or the Organization level. Custom roles are built from a catalog of granular permissions and defined at the group level, then assigned per org.
- Custom roles: Yes
- Custom roles plan: Enterprise
- Granularity: Permissions are broken down by resource type (projects, integrations, reports, members, service accounts, etc.) and action (view, create, edit, delete, test). Custom roles allow mixing and matching from this catalog.
How to add users
- Log in to app.snyk.io as an Org Admin or Group Admin.
- Navigate to the target organization.
- Click 'Members' in the left navigation.
- Click 'Add members'.
- Enter the invitee's email address.
- Select the role to assign (Org Admin or Org Collaborator, or a custom role if on Enterprise).
- Click 'Send invite'. The user receives an email invitation and must accept it to gain access.
Required fields: Email address of the invitee, Role selection
Watch out for:
- Invited users must accept the email invitation before they appear as active members; pending invites are visible in the Members list.
- Users must have or create a Snyk account using the same email address the invite was sent to.
- If SSO is enforced, users must authenticate via SSO; email/password login is blocked for those orgs.
- Adding a user to one org does not add them to other orgs in the same group; each org requires a separate invitation.
- On the Team plan, the organization is limited to a maximum of 10 licensed developers.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Snyk does not offer a 'deactivate' state for org members. Admins can remove a user from an organization, which revokes their access to that org's projects and data. The user's Snyk account itself is not deleted by this action; the user continues to exist in Snyk's system and may retain access to other orgs they belong to. Full account deletion requires the user to request it themselves via Snyk support.
- Log in to app.snyk.io as an Org Admin or Group Admin.
- Navigate to the target organization.
- Click 'Members' in the left navigation.
- Locate the user in the member list.
- Click the three-dot menu (⋯) next to the user's name.
- Select 'Remove from organization'.
- Confirm the removal in the dialog.
| Data impact | Behavior |
|---|---|
| Owned records | Projects, targets, and scan results created by the removed user remain in the organization; they are not deleted when the user is removed. |
| Shared content | Shared reports and project data remain accessible to remaining org members. |
| Integrations | SCM and other integrations configured by the removed user remain active; credentials or tokens tied to that user's personal auth may need to be rotated separately. |
| License freed | Removing a user from an org frees their seat in that org. On Enterprise with group-level licensing, the seat count decreases once the user is no longer a member of any org in the group. |
Watch out for:
- Removing a user from one org does not remove them from other orgs in the same group; each org must be managed separately.
- If the user authenticated via SSO and SSO provisioning (custom mapping) is active, the user may be re-provisioned on next SSO login unless the IdP group membership is also removed.
- Service accounts are separate from human user accounts and must be deleted independently via Settings → Service Accounts.
- Group Admins can view and remove users at the group level via the Group Members page, which shows membership across all orgs.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Developer seat (Team plan) | Access to Snyk products (Open Source, Code, Container, IaC) within the licensed org; limited to 10 seats per org | Approximately $25/developer/month (billed annually at ~$1,260/developer/year per published pricing) |
| Developer seat (Enterprise plan) | Access to all Snyk products, SSO, custom roles, group management, and advanced reporting; seat count negotiated with Snyk account team | Custom pricing; publicly reported range is $5,000–$70,000+ annually depending on developer count and products |
| Free seat | Limited test counts per month; single org; no SSO or custom roles | $0 |
- Where to check usage: app.snyk.io → [Group name] → Members → view 'Total members' count; or app.snyk.io → [Group name] → Reports for usage data on Enterprise
- How to identify unused seats: Group Admins can view the Members list at the group level, which shows last authentication date per user. Users who have not authenticated recently can be identified for removal. No built-in 'inactive user' report exists; admins must manually review the last-seen timestamps in the Members table.
- Billing notes: Snyk bills per unique developer (human user) seat. Service accounts do not consume developer seats. On Enterprise, seat counts and product entitlements are set at contract time; overages require coordination with the Snyk account team. The Team plan hard-caps at 10 developer seats.
The cost of manual management
Snyk has no native SCIM endpoint, so every provisioning and deprovisioning action is either manual or routed through SSO custom mapping (Enterprise only). Adding a user to one org does not add them to any other org in the same group - each org requires a separate invitation.
Removing a user follows the same pattern: every org must be managed individually, and the underlying Snyk account is never deleted by an admin action alone. There is no bulk-invite via CSV; large onboarding on non-Enterprise plans means one invite at a time.
What IT admins are saying
The most consistent friction reported by Snyk admins centers on three areas.
First, the absence of native SCIM means deprovisioning is not atomic - a user removed from an org can be silently re-provisioned on their next SSO login if the IdP group membership was not also revoked.
Second, there is no built-in inactive-user report; identifying unused seats requires manually reviewing last-login timestamps in the Members table. Third, SSO enforcement and custom roles are both gated behind Enterprise, leaving Team and Free plan customers with limited access governance options.
Common complaints:
- No native SCIM support; Enterprise customers must use Snyk's custom mapping approach via their IdP, which requires specific group naming conventions and coordination with the Snyk account team.
- Users removed from an org can be automatically re-provisioned on next SSO login if IdP group membership is not also revoked, creating a re-access risk.
- No CSV import for bulk user invitations; large org onboarding must be done via SSO provisioning or one-by-one invites.
- SSO is only available on Business and Enterprise plans; Team and Free plan customers cannot enforce SSO.
- Custom roles require Enterprise plan; lower-tier customers are limited to the three predefined roles.
- No built-in inactive-user report; admins must manually inspect last-login timestamps in the Members table to identify unused seats.
- Removing a user from one org does not cascade to other orgs in the group; multi-org offboarding requires manual repetition per org.
- Must pay for Enterprise to enable SSO.
The decision
Choose manual management if your team is small, org count is low, and you are not on Enterprise. The invite flow is straightforward, and Org Admin scope is sufficient for day-to-day member management within a single org.
Move toward SSO custom mapping (Enterprise) when you need to govern access across multiple orgs at scale - but plan for the IdP group naming conventions Snyk requires and coordinate with your Snyk account team before rollout.
In either path, every app your developers work in will reflect the org-level role you assign, so right-sizing roles at invite time reduces cleanup later.
Bottom line
Snyk's manual user management is functional but org-by-org, with no deactivation state and no bulk tooling below Enterprise.
The biggest operational risk is the re-provisioning gap: removing a user from Snyk without also removing them from the IdP group leaves a live re-entry path on their next SSO login.
Admins who need to govern access across every app connected to a Snyk group should treat IdP group membership and Snyk org membership as a paired action, not a sequential one.
Automate Snyk workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
