dbt Cloud User Management Guide

• Model type: hybrid
• Description: dbt Cloud uses a hybrid model combining account-level roles (Account Admin, Member) with project-level permission sets (Project Admin, Job Admin, Analyst, Stakeholder, etc.). On Team plan, permissions are simplified to account-level Member or Read-Only. On Enterprise, administrators can assign granular permission sets per project and per user, and can create custom roles by combining permission sets.
• Custom roles: Yes
• Custom roles plan: Enterprise
• Granularity: Project-level and environment-level on Enterprise; account-level only on Team and Developer plans.

1. Log in to dbt Cloud as an Account Admin.
2. Navigate to Account Settings (gear icon, top right) → Team → Members.
3. Click 'Invite Users'.
4. Enter the user's email address (one or multiple, comma-separated).
5. Select the license type: Developer or Read-Only.
6. Assign account-level role (Member or Account Admin).
7. On Enterprise, optionally assign project-level permission sets for each relevant project.
8. Click 'Send Invitations'. The user receives an email invitation to join the account.
9. User must accept the invitation and create or log in to their dbt Cloud account.

Required fields: Email address, License type (Developer or Read-Only), Account-level role

Watch out for:

• Invitations expire; if a user does not accept within the expiry window, the admin must resend.
• On SSO-enabled accounts, users may be required to authenticate via the configured IdP rather than email/password.
• Adding a Developer seat beyond the plan's included count immediately increases the billable seat count.
• On Enterprise with SCIM enabled, users can be provisioned automatically from the IdP; manual invitations are still possible but SCIM is the recommended path at scale.
• Project-level permission set assignment is only available on Enterprise; on Team, all members share the same account-level role.

• Can delete users: Verify in tenant
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Log in to dbt Cloud as an Account Admin.
2. Navigate to Account Settings → Team → Members.
3. Locate the user to remove.
4. Click the kebab menu (three dots) or 'Edit' next to the user.
5. Select 'Remove User' or 'Revoke Access'.
6. Confirm the action. The user loses access to the account immediately.
7. If SCIM is configured, deprovisioning the user in the IdP (e.g., removing from the dbt Cloud app in Okta) will also revoke access automatically.

Watch out for:

• Personal API tokens belonging to the removed user are not automatically revoked; admins should audit and revoke tokens manually via Account Settings → API Tokens.
• If the removed user was the sole Account Admin, another user must be promoted to Account Admin before removal to avoid losing admin access.
• Jobs scheduled under the removed user's credentials (e.g., personal git tokens or warehouse credentials) may fail after removal; credentials should be migrated to a service account or another user before removing.
• SCIM deprovisioning removes group memberships but does not guarantee immediate session termination if the user has an active session; session expiry depends on SSO session settings.
• There is no bulk-remove option in the UI; users must be removed one at a time manually.

• Where to check usage: Account Settings → Team → Members (shows all users, their license type, and last active date where available). Billing details visible under Account Settings → Billing.
• How to identify unused seats: Review the Members list for users with no recent login activity. dbt Cloud does not natively surface a 'last login' column in all plan tiers; admins may need to cross-reference with IdP login logs or audit logs (Enterprise) to identify inactive users.
• Billing notes: dbt Cloud bills on a combination of Developer seats and Successful Models Built (SMB) usage. Read-Only seats are not charged per seat. On Team, the first 15,000 successful model runs/month are included; overages are billed at $0.01/model. On Enterprise, 100,000 models/month are typically included in the negotiated contract. Seat counts are reconciled at billing cycle; removing a user mid-cycle may or may not result in a prorated credit depending on contract terms. Enterprise contracts are annual and negotiated directly with dbt Labs sales.

Every app in your stack that lacks automated provisioning adds recurring admin overhead, and dbt Cloud is no exception at scale. There is no bulk-invite via CSV and no bulk-remove option - each user must be handled individually in the UI.

Personal API tokens belonging to removed users are not automatically revoked, so every offboarding requires a separate manual audit under Account Settings → API Tokens. On Team plan, SCIM is unavailable, making every user lifecycle event a hands-on task.

The most consistent friction reported by dbt Cloud admins centers on three areas. First, the absence of a native last-login or activity report makes it hard to identify and reclaim unused Developer seats - admins must cross-reference IdP logs or Enterprise audit logs manually.

Second, SCIM and SSO are gated behind Enterprise, leaving Team-plan teams with no automated provisioning path. Third, the Team plan's coarse Member/Read-Only model is widely considered too blunt for real team structures, where project-level access control is the norm.

Common complaints:

• Enterprise pricing (~$300/seat/month list price) is considered very expensive for smaller data teams, with negotiation required to reach lower rates.
• SCIM and SSO are gated behind the Enterprise plan, forcing smaller teams on Team plan to manage users entirely manually.
• No bulk user removal or CSV import for invitations; large team onboarding requires individual invitations.
• Personal API tokens are not automatically revoked when a user is removed, creating a potential security gap that requires manual cleanup.
• Lack of a native 'last login' or user activity report in the admin UI makes it difficult to identify and reclaim unused Developer seats.
• Project-level permission granularity is only available on Enterprise; Team plan users find the binary Member/Read-Only model too coarse for real team structures.
• Enterprise+ plan required for PrivateLink and IP allowlisting, adding cost for security-sensitive organizations.
• Job ownership is not automatically transferred when a user is removed, requiring manual remediation to avoid broken scheduled jobs.

If your team is on the Team plan, every app access change is a manual, one-at-a-time operation with no automation escape hatch. Upgrading to Enterprise unlocks SCIM, granular project-level permissions, and audit logs - but Enterprise pricing is negotiated annually and starts high (list price is roughly $300/seat/month, negotiable).

Teams that need SSO-driven provisioning and fine-grained access control should factor the Enterprise requirement into their evaluation. Teams that only need read-only stakeholder access can add unlimited Read-Only seats at no additional per-seat cost on both Team and Enterprise plans.

Bottom line

dbt Cloud's manual user management is functional but friction-heavy at any meaningful scale: no bulk operations, no automatic token revocation on offboarding, and no native activity reporting to surface idle seats.

Every app access review requires cross-referencing external IdP data unless you are on Enterprise with audit logs enabled.

The platform is clearly designed to push larger teams toward SCIM-backed automation on Enterprise - if your team size or compliance posture justifies that investment, the manual overhead largely disappears; if not, expect recurring administrative lift with each hire or departure.