Apache Superset User Management Guide

• Model type: hybrid
• Description: Role-based access control (RBAC) implemented via Flask AppBuilder (FAB). Permissions are assigned to roles, and roles are assigned to users. Built-in roles (Admin, Alpha, Gamma, sql_lab, Public) are managed by Superset and re-synchronized on superset init. Custom roles can be created and combined (unioned) with built-in roles. Permissions are highly granular: model-level (can_add, can_delete, can_edit, can_show, can_list), view-level, datasource-level, and database-level. Row-Level Security (RLS) filters can be applied per role to restrict data rows returned by queries. Permissions are assigned programmatically at startup by SupersetSecurityManager; no static human-readable permission list is maintained.
• Custom roles: Yes
• Custom roles plan: Free (open source)
• Granularity: Model/action level (can_add, can_delete, can_edit, can_show, can_list per entity), view level, per-datasource, per-database, and row-level security (SQL WHERE clause filters per role). Approximately 280+ discrete permissions exist.

1. Log in as an Admin user.
2. Navigate to Settings → Security → List Users.
3. Click the '+' (Add) button to open the user creation form.
4. Enter required fields: First Name, Last Name, Username, Email, Password, Confirm Password.
5. Select one or more roles from the Roles multi-select field (e.g., Gamma, Alpha, sql_lab).
6. Click 'Save' to create the user.
7. Alternatively, create users via CLI: superset fab create-user --username <u> --firstname <f> --lastname <l> --email <e> --password <p> --role <role>.
8. Alternatively, enable FAB Security API (FAB_ADD_SECURITY_API = True in superset_config.py) and POST to /api/v1/security/users/.

Required fields: first_name, last_name, username, email, password, role (at least one)

Watch out for:

• The FAB REST API for user CRUD is in beta and disabled by default; requires FAB_ADD_SECURITY_API = True in superset_config.py.
• If user/role management options are missing from the Settings menu, run superset init to re-sync permissions.
• Users provisioned via LDAP or OAuth are created automatically on first login; they do not appear in the user list until they sign in.
• No native bulk CSV user import exists in the UI; bulk creation requires scripting via the CLI or API.
• Email notifications on user creation are only sent if an SMTP server is configured in superset_config.py.

• Can delete users: Yes
• Delete/deactivate behavior: User deletion is technically available via the UI (Settings → Security → List Users → delete icon) and via the FAB Security API (DELETE /api/v1/security/users/{pk}), but deletion frequently fails with a foreign key constraint error ('Associated data exists, please delete them first') if the user has any associated records in the metadata database (dashboards, charts, databases created_by, query logs, etc.). Even simply viewing a chart creates a log entry that blocks deletion. The recommended approach per Apache Superset documentation is to deactivate (set Active = False) rather than delete the user.

1. Log in as an Admin user.
2. Navigate to Settings → Security → List Users.
3. Click the edit (pencil) icon next to the target user.
4. Uncheck the 'Active' checkbox.
5. Click 'Save'. The user can no longer log in but their record and associated data are preserved.

Watch out for:

• Deleting a user who has ever viewed a chart will fail due to log table foreign key constraints, even if all their dashboards and charts have been deleted.
• To force-delete a user, all referencing records (logs, created_by on databases/datasets, ownership entries) must be manually removed from the metadata database first, which destroys audit history.
• Deactivated users still appear in the user list; there is no automatic cleanup or archival.
• When a user is removed from an upstream IdP (LDAP/OAuth), their Superset profile is not automatically deactivated; manual deactivation in Superset is required.
• The FAB Security API DELETE endpoint for users returns a 422 error with a foreign key constraint message when associated data exists.

• Where to check usage: Settings → Security → List Users (shows all registered users and their active status). Query the metadata database table ab_user for programmatic reporting.
• How to identify unused seats: No built-in inactive user report in the UI. Admins can query the logs table in the metadata database to find users with no recent activity, or filter the user list by last login date if exposed. The ab_user.last_login column in the metadata database can be queried directly.
• Billing notes: Apache Superset is open source (Apache 2.0 license) with no licensing fees or seat costs. Preset.io is the commercial managed offering with additional enterprise features and support tiers.

Because Apache Superset has no native SCIM and no UI-driven IdP sync, every joiner, mover, and leaver event must be handled manually by an admin inside Settings → Security → List Users.

Offboarding is particularly fragile: deleting a user who has ever viewed a chart fails with a foreign key constraint error ('Associated data exists, please delete them first'), meaning the practical offboarding action is deactivating the account rather than removing it. Deactivated users remain visible in the user list indefinitely with no archival or cleanup.

When a user is removed from an upstream IdP, their Superset profile is not automatically deactivated - admins must catch and act on each departure separately. With ~280+ largely undocumented permissions, building and auditing custom roles adds compounding overhead for any team managing more than a handful of users.

Community feedback consistently flags two pain points: permission opacity and broken deletion. One GitHub contributor noted that "permission management [is] tricky because there is little documentation on the subject" (Issue #27765, March 2024).

The Superset core team acknowledged in SIP-152 (February 2025) that "managing roles at the individual user level leads to inefficiencies and inconsistencies, making access control difficult to maintain and audit." The user deletion bug - surfaced by the UI error "Associated data exists, please delete them first" - has been open since February 2021 (Issue #13345) and affects any user who has ever interacted with a chart or dashboard.

Bulk user import via CSV does not exist in the UI; it requires CLI scripting or API calls. SSO setup complexity and the absence of SCIM are recurring themes across community discussions.

Common complaints:

• No out-of-box SAML support; requires custom security manager implementation.
• Custom development required for enterprise SSO (OAuth, LDAP configuration is code-based, not UI-driven).
• Complex authentication setup with no native SCIM provisioning.
• User deletion is broken in practice due to foreign key constraints from log entries; even viewing a chart blocks deletion.
• No native bulk user import via CSV in the UI; requires CLI scripting or API calls.
• ~280+ permissions are largely undocumented and unintelligible to administrators, making custom role creation very difficult.
• Built-in role permissions are overwritten on every superset init run, making manual customization of base roles fragile.
• No user groups feature (SIP-152 proposed but not yet shipped as of early 2026); roles must be assigned individually to each user, creating scaling problems.
• Granting chart-level access without granting access to all dashboards sharing the same dataset is difficult to configure correctly.
• Adding permissions to the Public role can unexpectedly remove API permissions from the Admin role (known bug).
• User and role management options can disappear from the Settings menu after authentication type changes or incomplete builds, requiring superset init re-run.

Manual management of Apache Superset is workable for small, stable teams where user churn is low and an engineer is available to handle config-level SSO setup.

It becomes a liability at scale: every offboarding requires a manual deactivation step that is decoupled from your IdP, role auditing across ~280+ permissions is largely undocumented, and there is no bulk import path in the UI.

Teams running Superset as part of a broader SaaS portfolio - where every app needs consistent access governance - will find the absence of SCIM and the broken delete behavior create meaningful audit and compliance gaps. The commercial managed offering, Preset, provides easier IdP integration but is a separate product with its own pricing.

Bottom line

Apache Superset gives you a fully featured BI platform at zero licensing cost, but that cost is paid in operational overhead: no SCIM, no UI-driven SSO, a user deletion flow that fails in practice due to database constraints, and a permission system with ~280+ options that are largely undocumented.

For teams where every app in the identity stack needs reliable, auditable lifecycle management, Superset's manual-only provisioning model creates persistent gaps - particularly around offboarding, where deactivation must be performed manually in Superset even after a user is removed from the IdP.