Users, roles & SSO
Two base roles cover most orgs. A Member can run sessions and contribute to the shared assets that make sessions better: knowledge, playbooks, and machine snapshots. An Admin can do all of that plus manage billing, integrations, secrets, and org settings. Enterprise plans add account-level roles and custom roles for finer-grained RBAC when those two aren't enough.
There are two ways to get people in:
- Manual invites. Settings → Members → Invite. Fine for a small team or a pilot, and it's how you'll add the occasional contractor or org admin by hand.
- SSO with IdP groups. The scale path. Connect SAML or OIDC through your identity provider (Okta, Azure AD, and similar), define groups in the IdP, and map each group to a Devin org and role. New hires land in the right org with the right role the first time they log in, without a ticket to you.
Now the caveat that catches almost every admin: Devin's provisioning is login-triggered, not real-time. A user is created in Devin the first time they log in through SSO, and their group memberships sync at login time, not when you change them in the IdP. Most importantly, deprovisioning is manual: removing a user from your IdP blocks their next SSO login, but it does not remove them from Devin orgs. The docs describe a recommended "SCIM-like" setup that gets you close to automatic provisioning; check the SSO docs for current SCIM support rather than assuming enterprise-grade sync, and know the limits of whatever your plan supports.
Role assignment can ride the same rails: map IdP groups to roles so that, say, membership in a devin-admins group grants org Admin automatically. If you build custom roles, follow least privilege and resist one-off roles per person; a pile of near-duplicate roles is harder to audit than a slightly-too-broad standard one.
Since deprovisioning is manual, run through all three of these steps when someone leaves:
- Remove the user from the IdP group (blocks future logins).
- Remove them from their Devin orgs (revokes access that already exists).
- Revoke any personal API keys or service users they controlled.
Skip step 2 and a departed employee stays a member of your orgs; skip step 3 and their automation keeps running under their name. Do all three, every time.