Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

This guide walks enterprise administrators through the full SSO lifecycle with Devin — from initial setup through IdP group configuration — and explains how Devin handles user provisioning without SCIM. For provider-specific setup instructions, see Okta, Azure AD, SAML, or Generic OIDC.

​
1. Setting Up SSO

​
Creating Your SSO Application

Create an application in your identity provider (Okta, Azure AD, or any SAML/OIDC-compliant IdP) and share the following credentials with your Cognition team:
Connection TypeProtocolWhat to Provide
OktaOIDC (Okta Workforce Identity)Okta domain, Client ID, Client Secret, Scopes
Azure ADOIDC (Microsoft Entra ID)Azure AD domain, Client ID, Client Secret
SAMLSAML 2.0 (any IdP)Sign-In URL, X.509 Signing Certificate
Generic OIDCOIDCDiscovery URL, Client ID, Client Secret, Scopes
You should also provide your verified email domain(s) so Devin knows which email addresses to trust from your IdP.

​
What Happens After Setup

Once your Cognition team has the credentials, they configure the SSO connection. After setup is complete:
  1. The SSO connection is linked to your Devin enterprise
  2. Auto-membership on login is enabled — any user who authenticates via SSO is automatically added to your enterprise
  3. Your email domain(s) are registered as trusted — only emails from those domains are accepted
  4. Group-based role assignment (RBAC) is enabled — IdP groups sent during login can be mapped to Devin roles
  5. Default social logins (Google, GitHub) are disabled — SSO becomes the required authentication method

​
The User Login Experience

  1. User navigates to your Devin URL
  2. Redirected to the configured IdP (Okta, Azure AD, etc.)
  3. User authenticates normally
  4. The IdP sends user info and group memberships back to Devin
  5. Devin automatically:
    • Creates the user’s account if it’s their first login (just-in-time provisioning)
    • Assigns them the default Enterprise Member role
    • Syncs their IdP group memberships — adds new groups, removes stale ones
    • Records the login in the enterprise audit log

​
Self-Service Administration

The following are available to enterprise admins directly in the Devin webapp.

​
IdP Group Management

Settings → Enterprise → Identity Provider Groups
  • View all groups that have been synced from user logins
  • Assign a group to an enterprise-level role (e.g., “Everyone in Engineering-Admins gets the Enterprise Admin role”)
  • Assign a group to specific orgs with specific roles (e.g., “Team-Backend gets Member access in the Backend org”)
  • Bulk add/remove groups across multiple orgs
  • View how many orgs each group is assigned to

​
Member Management

Settings → Enterprise → Members
  • View all enterprise members, including their IdP group memberships
  • Invite new members by email
  • Update member roles
  • Remove members

​
Custom Roles

Settings → Enterprise → Roles
  • Create custom roles with granular permissions
  • Assign custom roles to individual users or to IdP groups
See Custom Roles & RBAC for details.

​
API for Automation

Devin provides a V2 API you can use to automate member management:
ActionAPI Endpoint
List all membersGET /v2/enterprise/members
Invite users by email (bulk)POST /v2/enterprise/members/invite
Remove a memberDELETE /v2/enterprise/members/{user_id}
Bulk update member rolesPATCH /v2/enterprise/members/roles
Migrate members between rolesPATCH /v2/enterprise/members/migrate-roles
List all rolesGET /v2/enterprise/roles
List all IdP groupsGET /v2/enterprise/groups
Pre-create IdP groupsPUT /v2/enterprise/groups
Get a group’s org assignmentsGET /v2/enterprise/groups/{group_name}

​
2. Understanding Devin Without SCIM

Devin does not currently support the SCIM protocol. All user and group management happens through SSO login events and the Devin UI/API. Here is what that means in practice.

​
User Provisioning: Login-Triggered Only

With SCIMDevin (Without SCIM)
How users are createdIdP pushes user creation to app immediately when user is assignedUser only exists in Devin after their first SSO login — or after manual invite via the UI or API
When it happensAdmin assigns app to user → user appears within secondsAdmin assigns app to user → nothing happens in Devin until they log in
Pre-provisioningUser account is ready before they ever visit the appNo pre-provisioning unless admin explicitly invites them via the Devin UI or API
When onboarding new employees, the admin can either invite them in advance (Settings → Enterprise → Members → Invite, or via the API) or simply let them be auto-provisioned on first login.

​
User Deprovisioning: Manual Only

With SCIMDevin (Without SCIM)
How users are removedIdP deactivates/removes user → app immediately disables the userDeactivating/removing a user in the IdP does nothing in Devin
OffboardingOffboarded employee loses access within minutesOffboarded employee retains access until manually removed from Devin and their session expires
ComplianceAutomated compliance — no orphaned accountsRisk of orphaned accounts unless the admin maintains both systems
This is the biggest operational gap. When offboarding an employee, the admin must separately remove them from Devin (Settings → Enterprise → Members → Remove, or via the API). Active sessions continue working until they naturally expire — there is no instant session revocation triggered by the IdP.

​
Group Sync: Login-Time Only, Not Real-Time

With SCIM (Group Push)Devin (Without SCIM)
Sync timingIdP pushes group membership changes in real-timeGroups only sync when the user logs in
Adding to a groupAdmin adds user to group → app reflects it immediatelyAdmin adds user to group → Devin doesn’t know until user’s next login
Removing from a groupAdmin removes user from group → app reflects it immediatelyAdmin removes user from group → Devin still shows old membership until next login
Source of truthIdP is always the source of truthIdP is source of truth only at login time — can drift between logins
If an admin changes someone’s IdP group (e.g., moves them from Engineering to Sales), Devin won’t reflect this until the user logs in again. In the meantime, the user keeps their old group-based roles and org access.

​
Built-in Alternatives to SCIM

Devin includes several features that address common SCIM use cases:
  1. Just-in-time provisioning — users are auto-created on first SSO login with the default enterprise role
  2. Full group sync on every login — every time a user logs in, Devin does a complete diff of their IdP groups: adds new ones, removes old ones
  3. Group-based RBAC — you can map IdP groups to enterprise roles and org access in the Devin settings, taking effect on next login
  4. V2 API for automation — invite, remove, and bulk role changes can be scripted to close the provisioning/deprovisioning gap
  5. Audit logs — every login is recorded, providing visibility into who has accessed Devin

​
3. Configuring IdP-Managed Groups

If you use SCIM with other applications (e.g., Slack, Box), this section explains how Devin’s group model works and how to configure your IdP correctly.

​
Context: SCIM Groups vs IdP Groups

  • SCIM Groups: The downstream app tells the IdP what groups exist (the IdP “imports” them). The app is the source of truth for group structure. The IdP syncs users into those app-defined groups.
  • IdP Groups (what Devin uses): The IdP is the source of truth. Groups are defined in the IdP’s directory, and group memberships flow to Devin via SAML/OIDC claims at login time.
Since Devin does not use SCIM, you are already operating in “IdP groups” mode. The key is making sure the right groups are being sent from your IdP and mapped correctly in Devin.

​
Step 1: Define Groups in the IdP

In your IdP Admin Console (examples below use Okta):
  1. Go to Directory → Groups
  2. Create groups that map to Devin access levels (e.g., Devin-Engineering, Devin-Admins, Devin-DataScience)
  3. Assign users to these groups
These are IdP-native groups — your IdP is the source of truth for who belongs to what.

​
Step 2: Configure Group Claims in the IdP App

The groups must be included in the authentication response so Devin can read them.

​
For SAML Connections

  1. Go to Applications → [Devin App] → SAML Settings → Edit
  2. Under Group Attribute Statements, add:
    • Name: groups
    • Filter: “Starts with” → Devin- (or use “Matches regex” for more complex patterns)
  3. This tells the IdP to include matching group names in the SAML assertion

​
For OIDC Connections

  1. Go to Applications → [Devin App] → Sign On → Edit
  2. Under OpenID Connect ID Token → Groups claim type, select “Filter”
  3. Set the filter to match Devin groups (e.g., “Starts with” → Devin-)
Use a filter prefix like Devin- so only relevant groups are sent. There’s no need to send every IdP group in the organization.

​
Step 3: Map Groups to Roles and Orgs in Devin

Once groups are flowing through on login, map them in Devin.

​
In the Devin UI

  1. Settings → Enterprise → Identity Provider Groups
  2. Groups appear automatically after any member of that group logs in
  3. Click a group → assign it an enterprise-level role (e.g., Enterprise Admin, or a custom role)
  4. Click a group → assign it to specific orgs with specific org-level roles

​
Via the API (for Pre-Setup or Automation)

  • Pre-create groups before anyone logs in: PUT /v2/enterprise/groups
  • List groups and their org assignments: GET /v2/enterprise/groups

​
Step 4: If Migrating from SCIM Groups in Other Apps

If you are shifting your overall IdP strategy from SCIM-managed groups to IdP-managed groups across your tooling (not just Devin):
  1. Stop SCIM Group Importing in the other apps:
    • In the IdP: go to the app’s Provisioning → Integration tab → uncheck “Import Groups”
    • This stops the downstream app from being the source of truth for groups
  2. Create Matching Groups in the IdP Directory:
    • Go to Directory → Groups and create groups that mirror what existed in the downstream app
    • Assign users to these IdP-native groups
  3. Configure Group Push (for apps that support it):
    • In the app’s IdP config: Push Groups tab → Find groups by name → Link to existing downstream groups
    • This makes the IdP overwrite the app’s internal membership — the IdP becomes the single source of truth
    • Devin doesn’t need Group Push because it reads groups directly from the login assertion
  4. Disable SCIM Group Sync in the other apps:
    • Ensure “Import Groups” stays off to prevent the downstream app from re-asserting as source of truth
For Devin specifically, no migration is needed. Just ensure Steps 1–3 above are done (groups defined in your IdP, claims configured, mappings set in Devin).

​
Key Considerations

If a group is renamed, Devin treats it as a new group. The old group’s role mappings don’t transfer automatically — you will need to reconfigure the new group name in Devin’s settings.
A user added to a Devin-mapped IdP group won’t gain that access until they log in.
Removing a user from an IdP group doesn’t immediately revoke their Devin access. On their next login, Devin syncs and removes the stale group membership. Any direct membership (assigned outside of groups) is unaffected.
The group name in the IdP must exactly match what Devin sees. Case-sensitive.
Devin doesn’t support nested/hierarchical groups. If the IdP sends a parent group, child group members aren’t automatically included. Each group must be explicitly assigned.
For the tightest possible control without SCIM, follow this approach:
1

Configure your Identity Provider (Source of Truth)

  1. Define groups: Devin-Admins, Devin-Backend, Devin-Frontend, etc.
  2. Assign users to groups
  3. Configure SAML/OIDC group claims filtered to “Starts with: Devin-”
2

Devin syncs on every login

When a user logs in via SSO, Devin automatically:
  • Auto-creates the user if new
  • Performs a full group sync (adds new groups, removes stale ones)
  • Applies group-to-role and group-to-org mappings immediately
3

Optional: Automate with the V2 API

Set up a scheduled job to close SCIM gaps:
  1. Read active users from your IdP API
  2. Read Devin members from GET /v2/enterprise/members
  3. Invite new employees via POST /v2/enterprise/members/invite
  4. Remove departed employees via DELETE /v2/enterprise/members/{user_id}
This gives you push-style provisioning and deprovisioning without SCIM.

​
What This Gives You

  • Your IdP as single source of truth for group structure and membership
  • Automatic group-based access on every login
  • API-driven provisioning/deprovisioning to close the gap SCIM would normally fill
  • Full audit trail for all logins and membership changes

​
Current Limitations

  • Real-time group sync between logins — groups only update when users log in
  • Instant session revocation on deprovisioning — sessions live until they expire
  • IdP-initiated lifecycle events like suspend/reactivate are not supported