Summary and recommendation
Domino Data Lab 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.
Domino Data Lab uses a two-layer permission model: a system-level Admin role and project-level roles (Owner, Contributor, Results Consumer).
Admins manage every app and user from the Admin Panel, reachable via the top-right account menu at `https://<your-domino-instance>/admin/users`.
No SSO prerequisite is required to use the platform, but SCIM-based provisioning requires the Enterprise plan.
Quick facts
| Admin console path | Admin Panel > Users (accessible via the top-right account menu for users with the Admin system role) |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| System Administrator (Admin) | Full platform access: manage all users, projects, environments, hardware tiers, billing, and system settings. Can deactivate users and assign roles. | Admin role is a system-level designation, not a project-level role. Admins can access all projects regardless of project-level permissions. | |||
| Regular User (Data Scientist / Analyst) | Can create and run projects, publish models, use shared datasets, and collaborate on projects they are invited to. | Cannot access Admin Panel, manage other users, or modify system-level settings. | Custom pricing; license type (Data Analyst or Data Science Professional) determines feature access. | License type (Data Analyst vs. Data Science Professional) gates access to certain compute and collaboration features. Assigning the wrong license type may restrict user capabilities. | |
| Project Owner | Full control over a specific project: add/remove collaborators, change project settings, delete the project. | Cannot manage platform-level users or system settings. | Project Owner is a project-scoped role, not a platform role. A user can be Owner of one project and Contributor on another. | ||
| Contributor | Can run jobs, edit code, and collaborate within a project they have been added to. | Cannot change project settings or add/remove other collaborators. | |||
| Results Consumer | Read-only access to project results and published model outputs within a specific project. | Cannot run jobs, edit code, or modify project settings. | Results Consumer seats may have different licensing implications; verify with Domino account team. |
Permission model
- Model type: hybrid
- Description: Domino uses a two-layer permission model: system-level roles (Admin vs. regular user) and project-level roles (Owner, Contributor, Results Consumer). System Admins can override project-level access. Project-level roles are assigned per project by the Project Owner or Admin.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: System-level (Admin/User) and project-level (Owner/Contributor/Results Consumer). No documented support for creating fully custom named roles beyond the built-in set.
How to add users
- Log in as a System Administrator.
- Navigate to the Admin Panel via the top-right account menu.
- Select 'Users' from the left sidebar.
- Click 'Add User' or 'Invite User'.
- Enter the required user details (username, email, password or SSO identity).
- Assign the appropriate license type (e.g., Data Analyst, Data Science Professional).
- Save to create the account. The user receives an email invitation if email is configured.
Required fields: Username, Email address, License type
Watch out for:
- If SSO/SAML is enabled, user accounts may need to match the identity provider's user attributes exactly to avoid login failures.
- License type must be assigned at creation; the wrong license type restricts feature access and may require Admin intervention to correct.
- In self-hosted (on-premises) deployments, email invitation delivery depends on SMTP configuration by the platform admin.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Public docs emphasize deactivation in the admin UI, but the API surface also exposes a DELETE-style lifecycle operation. Treat permanent-delete behavior as deployment-specific and confirm before relying on it in production.
- Log in as a System Administrator.
- Navigate to Admin Panel > Users.
- Locate the user by searching their username or email.
- Click on the user's name to open their profile.
- Select 'Deactivate User' (or toggle the active/inactive status).
- Confirm the deactivation when prompted.
| Data impact | Behavior |
|---|---|
| Owned records | Projects, runs, datasets, and files owned by the deactivated user remain on the platform and are accessible to collaborators and Admins. |
| Shared content | Shared projects the deactivated user was a member of remain intact; other collaborators retain their access. |
| Integrations | API keys and tokens associated with the deactivated user are invalidated upon deactivation, which may break automated pipelines using those credentials. |
| License freed | Deactivating a user frees the seat/license for reassignment to another user. |
Watch out for:
- If the deactivated user was the sole Owner of a project, an Admin must reassign project ownership to prevent the project from becoming unmanageable.
- API keys tied to the deactivated user will stop working immediately; any scheduled jobs or integrations using those keys will fail.
- Reactivating a user restores their login access and role assignments; data is not lost during deactivation.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Data Analyst License | Access to Domino for data analysis workflows; may have restrictions on compute tier access or advanced MLOps features compared to the Data Science Professional license. | Custom pricing; contact Domino sales. |
| Data Science Professional License | Full access to Domino's MLOps capabilities including model deployment, advanced compute, and collaboration features. | Custom pricing; contact Domino sales. |
| Domino Cloud Consumption Units (Enterprise) | Usage-based compute consumption model for Domino-hosted (cloud) deployments, in addition to per-seat licensing. | Custom; billed based on compute consumption. |
- Where to check usage: Admin Panel > Users (shows active vs. inactive users and their assigned license types); billing/usage dashboards may vary by deployment type.
- How to identify unused seats: Admins can review the Users list in the Admin Panel and filter by last login date or activity to identify inactive accounts. No dedicated 'unused seat' report is documented in official sources.
- Billing notes: Domino uses custom enterprise pricing. Deactivating a user frees their seat for reassignment. Domino Cloud deployments also incur compute consumption charges separate from seat licenses. Pricing details require direct engagement with the Domino sales team.
The cost of manual management
Every app onboarding or offboarding action in Domino requires a System Administrator to act manually through the Admin Panel - there is no bulk CSV import for users without an IdP or SCIM setup.
Deactivating a user does not auto-transfer project ownership, so Admins must manually reassign any projects the departing user owned to prevent them from becoming unmanageable. API keys tied to a deactivated user stop working immediately, meaning any scheduled pipelines or integrations using those keys will silently fail if not rotated before offboarding.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Domino is well-suited for enterprise data science teams that already operate an IdP and can enable SCIM for lifecycle automation. Teams without an IdP will manage every app user manually through the Admin Panel, which is workable at small scale but becomes operationally heavy as headcount grows. License type (Data Analyst vs.
Data Science Professional) must be assigned correctly at account creation - the wrong assignment restricts feature access and requires Admin intervention to fix.
Bottom line
Domino Data Lab's permission model is straightforward at the system level but adds complexity through project-scoped roles that must be managed independently per project.
Manual administration is fully functional for smaller teams, but the lack of bulk import, permanent deletion, and automatic ownership transfer on deactivation creates compounding overhead at scale.
Organizations managing every app in their stack through a centralized IdP will get the most operational leverage by enabling SCIM on the Enterprise plan.
Automate Domino Data Lab 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.
