Summary and recommendation
Snowflake 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.
Snowflake user management lives in Snowsight under Admin → Users & Roles.
Provisioning and deprovisioning are role-gated: you need at minimum USERADMIN, though SECURITYADMIN or ACCOUNTADMIN is required for broader privilege work.
Snowflake's permission model is RBAC layered over discretionary access control - privileges attach to roles, roles attach to users, and users can hold multiple roles simultaneously.
Quick facts
| Admin console path | Snowsight → Admin → Users & Roles |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Standard and above |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| ACCOUNTADMIN | Top-level system role. Full control over account, users, roles, warehouses, databases, billing, and security settings. Can grant any privilege. | Should not be used for day-to-day operations per Snowflake best practice. Cannot be granted to a role other than directly to a user. | All editions | Consumption-based; no per-seat fee for the role itself | Snowflake recommends limiting ACCOUNTADMIN to a small number of users and not using it as a default role for regular work. |
| SECURITYADMIN | Can manage users and roles account-wide. Inherits USERADMIN privileges. Can grant and revoke privileges on any object. | Cannot manage billing or account-level settings reserved for ACCOUNTADMIN. | All editions | Consumption-based; no per-seat fee for the role itself | SECURITYADMIN inherits USERADMIN, so users with this role can create and manage all users. |
| USERADMIN | Can create and manage users and roles. Intended for user provisioning tasks. | Cannot manage warehouses, databases, or account-level security settings beyond user/role management. | All editions | Consumption-based; no per-seat fee for the role itself | USERADMIN can only manage objects it owns or has been explicitly granted privileges on. |
| SYSADMIN | Can create and manage warehouses, databases, schemas, and other objects. Recommended role for object ownership. | Cannot manage users or roles by default. | All editions | Consumption-based; no per-seat fee for the role itself | Custom roles should be granted to SYSADMIN so that object ownership is manageable. |
| PUBLIC | Default role automatically granted to every user. Provides minimal baseline access. | Cannot access any data objects unless explicitly granted. Cannot perform administrative actions. | All editions | Consumption-based; no per-seat fee for the role itself | Any privileges granted to PUBLIC are available to all users in the account. |
| Custom Role | User-defined roles with any combination of privileges granted by an administrator. | Cannot exceed the privileges of the granting role (privilege escalation is not possible). | All editions | Consumption-based; no per-seat fee for the role itself | Custom roles must be granted to SYSADMIN or higher in the role hierarchy to ensure manageability. |
Permission model
- Model type: role-based
- Description: Snowflake uses discretionary access control (DAC) combined with role-based access control (RBAC). Privileges are granted to roles, and roles are granted to users. Users can hold multiple roles and switch between them. All securable objects have an owner role. Privilege grants are cumulative within a session's active role hierarchy.
- Custom roles: Yes
- Custom roles plan: All editions
- Granularity: Object-level and privilege-level: privileges can be granted on account, database, schema, table, view, warehouse, stage, file format, function, procedure, and other object types. Future grants allow automatic privilege assignment to new objects created within a schema or database.
How to add users
- Log in to Snowsight as a user with USERADMIN, SECURITYADMIN, or ACCOUNTADMIN role.
- Navigate to Admin → Users & Roles → Users.
- Click '+ User' button in the top-right corner.
- Enter the required fields: username, and optionally email, display name, default role, default warehouse, default namespace.
- Set authentication method: password, or configure for SSO/federated authentication.
- Optionally assign roles to the user at creation time.
- Click 'Create User'. Snowflake generates a temporary password if password authentication is used; the user must change it on first login.
- Alternatively, use SQL: CREATE USER
PASSWORD=' ' DEFAULT_ROLE= DEFAULT_WAREHOUSE= MUST_CHANGE_PASSWORD=TRUE;
Required fields: USERNAME (login name)
Watch out for:
- Username (LOGIN_NAME) must be unique within the account; it is case-insensitive by default.
- If no DEFAULT_ROLE is set, the user's active role defaults to PUBLIC.
- MUST_CHANGE_PASSWORD defaults to FALSE; Snowflake recommends setting it to TRUE for new password-based users.
- Users created without an email address cannot use password reset via email.
- For SSO/federated users, a password is not required but the account must have SSO configured.
- Users are not automatically granted any functional roles; roles must be explicitly granted after creation.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | All editions (SCIM 2.0 supported with Okta and Azure AD; SSO must be configured first) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Snowflake supports both disabling (deactivating) a user and permanently dropping (deleting) a user. Disabling sets DISABLED=TRUE, preventing login while preserving the user object and all associated metadata. DROP USER permanently removes the user object from the account. Dropped users cannot be restored. Objects owned by a dropped user are not automatically reassigned; ownership must be transferred before or after dropping.
- Via SQL: ALTER USER
SET DISABLED = TRUE; - Via Snowsight: Navigate to Admin → Users & Roles → Users, click the user's name, then use the 'Disable User' option in the user detail panel.
- To re-enable: ALTER USER
SET DISABLED = FALSE;
| Data impact | Behavior |
|---|---|
| Owned records | Objects (databases, schemas, tables, etc.) owned by the user remain in place after disabling or dropping. Ownership of objects must be explicitly transferred using GRANT OWNERSHIP before or after the user is dropped to avoid orphaned objects. |
| Shared content | Shares and data shared by the user's owned objects are not automatically affected by disabling the user, but dropping the user without transferring ownership of shared objects may cause access issues. |
| Integrations | Any tasks, pipes, streams, or integrations running under the user's credentials will fail after the user is disabled or dropped. Service accounts used for integrations should have ownership transferred before removal. |
| License freed | Snowflake is consumption-based; disabling or dropping a user does not reduce a fixed seat cost. Compute credits are only consumed when warehouses are active, so removing a user's ability to run queries reduces potential future consumption. |
Watch out for:
- DROP USER will fail if the user owns objects that have dependencies; ownership must be transferred first.
- Dropped users cannot be restored; the username can be reused by creating a new user with the same login name.
- Disabling a user does not terminate active sessions immediately; existing sessions may continue until they expire or are explicitly terminated.
- SCIM-provisioned users that are deprovisioned via IdP are set to DISABLED=TRUE in Snowflake, not dropped.
- Service account users used by SnowSQL, connectors, or drivers should be disabled rather than dropped until all dependent integrations are updated.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Compute Credits | Virtual warehouse usage billed per credit consumed. Credit rate depends on edition (Standard, Enterprise, Business Critical, VPS). | Standard: $2.00/credit (on-demand); Enterprise: $3.00/credit (on-demand); Business Critical: $4.00/credit (on-demand). Pre-purchased capacity discounts of 10–30% available. |
| Storage | Data stored in Snowflake (tables, stages, fail-safe, time travel). Billed monthly. | $23/TB/month (on-demand, US regions; varies by region and cloud provider) |
| Serverless Features | Snowpipe, automatic clustering, materialized view maintenance, database replication, search optimization. Billed by Snowflake-managed compute credits. | Varies by feature; billed at Snowflake-managed credit rates |
- Where to check usage: Snowsight → Admin → Cost Management (for credit and storage usage); also queryable via SNOWFLAKE.ACCOUNT_USAGE schema views (e.g., QUERY_HISTORY, WAREHOUSE_METERING_HISTORY, STORAGE_USAGE)
- How to identify unused seats: Query SNOWFLAKE.ACCOUNT_USAGE.USERS view to see last login timestamps. Query SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY to identify users who have not logged in within a defined period. Disabled users do not consume compute credits.
- Billing notes: Snowflake does not charge per-user seat fees. All billing is consumption-based on compute credits used and data stored. Users themselves do not have a direct cost; cost is incurred when users run queries on active warehouses. Pre-purchased capacity (Snowflake Capacity) offers discounts over on-demand rates.
The cost of manual management
Snowflake does not charge per-user seat fees. All billing is consumption-based: compute credits are consumed when users run queries on active virtual warehouses, and storage is billed monthly per TB. Disabled users do not consume compute credits, making timely deprovisioning a direct lever on spend.
Pre-purchased capacity offers 10–30% discounts over on-demand rates, but no pricing tier gates user management features - SCIM 2.0 is available on all editions.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual provisioning via Snowsight is viable for small, stable teams where every app in the stack is managed ad hoc and automation overhead isn't justified.
For organizations running Okta or Azure AD (Entra ID), SCIM 2.0 is the recommended path - it handles create, update, and disable operations automatically, though it will not delete user objects or reassign owned objects on deprovision.
Key decision factors:
- If SSO is already in place, SCIM adds relatively low setup cost and eliminates manual create/disable steps.
- If your team relies on custom or non-standard IdPs, the generic SCIM endpoint is supported but requires more configuration work.
- Service account users (SERVICE type) are not provisionable via SCIM and must be managed via SQL or the REST API.
- For every app that feeds data into or queries Snowflake programmatically, key-pair authentication is the correct auth pattern - not passwords.
Bottom line
Snowflake's manual user management is straightforward for small teams but does not scale gracefully: there is no bulk import, SCIM token expiration creates recurring operational risk, and deprovisioning requires ownership cleanup before a user can be fully removed.
Organizations with an existing Okta or Azure AD deployment should prioritize SCIM setup to reduce toil, while keeping a documented SCIM token rotation schedule to avoid provisioning outages.
Service accounts and programmatic users sit outside the SCIM boundary entirely and require a separate key-pair or OAuth management process.
Automate Snowflake 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.
