Summary and recommendation
Relativity 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.
RelativityOne uses a group-based permission model where all access is mediated through group membership at the workspace level.
Creating a user account grants no access on its own - the user must be added to a group, and that group must be assigned to every app and workspace separately.
System Administrator status is a flag on the user record, not a group role, and bypasses all group-based permission controls.
Quick facts
| Admin console path | RelativityOne > Home > Users (under the Admin section of the left navigation) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | N/A |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| System Administrator | Full access to all system-level settings, user management, group management, workspace creation, and all admin functions across the RelativityOne instance. | System Administrator status is a flag on the user account, not a group membership. It grants access outside of normal group-based permission controls. | |||
| Standard User | Access determined entirely by group membership and the permission sets assigned to those groups within each workspace. No inherent permissions outside of group assignments. | Cannot access any workspace or system function unless explicitly added to a group with appropriate permissions. | Users must be added to at least one group and that group must be added to a workspace for the user to access that workspace. |
Permission model
- Model type: role-based
- Description: RelativityOne uses a group-based permission model. Permissions are assigned to groups at the workspace level using predefined and customizable permission sets. Users inherit permissions through group membership. System Administrators bypass group-based restrictions. Workspace-level permissions are configured separately from instance-level permissions.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Permissions are configurable at the object type, tab, browser, and mass operation level within each workspace. Admins can enable or disable specific actions (view, edit, delete, add) per object type per group.
How to add users
- Log in as a System Administrator.
- Navigate to Home > Users from the left navigation panel.
- Click 'New User' to open the user creation form.
- Enter required fields: First Name, Last Name, Email Address, and Password (or configure SSO).
- Set the user's default selected file type, document viewer, and other preferences as needed.
- Optionally assign the user as a System Administrator by toggling the System Admin flag.
- Save the user record.
- Navigate to Home > Groups, open the relevant group, and add the new user to the group.
- Ensure the group is added to the relevant workspace(s) with appropriate permission sets.
Required fields: First Name, Last Name, Email Address, Password (if not using SSO)
Watch out for:
- Creating a user account does not grant any workspace access; group membership and workspace group assignment are required separately.
- Email address must be unique across the instance.
- If SSO is configured, password management may be handled by the identity provider rather than within Relativity.
- Users without group membership will see no workspaces upon login.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Unknown | Not documented |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Relativity's official documentation describes disabling user accounts by setting the user's status to 'Inactive', which prevents login without removing the user record. Whether full deletion of a user record is supported is not explicitly confirmed in currently available official documentation.
- Log in as a System Administrator.
- Navigate to Home > Users.
- Locate and open the user record.
- Set the user's 'Relativity Access' field to 'Disabled' (or set the account to Inactive depending on version).
- Save the user record.
| Data impact | Behavior |
|---|---|
| Owned records | Documents, objects, and records created by the user remain in the workspace and are not removed when the user is deactivated. |
| Shared content | Saved searches, views, and other shared objects created by the user persist after deactivation. |
| Integrations | Not documented |
| License freed | Disabling a user account removes their ability to log in; whether this immediately frees a billable seat depends on the specific contract and usage-based billing terms with Relativity. |
Watch out for:
- Deactivating a user does not remove them from groups; group membership should be reviewed separately.
- Billing impact of deactivation depends on contract terms, which are usage-based and negotiated individually.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| User Account | Access to RelativityOne workspaces as determined by group permissions. Relativity pricing is primarily usage-based (per-GB of data hosted/processed) rather than per named seat in the traditional SaaS sense. | Custom; usage-based pricing per GB. Named user seat costs are not publicly listed. |
- Where to check usage: Home > Users (view active user count); billing and usage details are managed through the Relativity billing portal or account management team.
- How to identify unused seats: Admins can review the 'Last Login' field on user records in Home > Users to identify accounts that have not been accessed recently.
- Billing notes: Relativity pricing is custom and usage-based (per-GB of data stored and processed). There is no publicly listed per-seat price. Billing is managed through individual contracts. Contact Relativity account management for seat and usage reporting.
The cost of manual management
Relativity pricing is usage-based (per-GB of data stored and processed) under individually negotiated contracts - there is no publicly listed per-seat price. Deactivating a user sets their account to Inactive, which blocks login but does not remove the record or automatically remove group memberships.
Billing impact of deactivation depends entirely on contract terms and should be confirmed with your Relativity account team. There is no bulk CSV import in the standard UI, so large onboarding events require creating users one at a time.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual administration is viable for small, stable teams with infrequent user changes and a limited number of workspaces. For organizations where every app and workspace requires its own group assignment, the per-workspace model creates compounding overhead as headcount or workspace count grows.
There is no native SCIM endpoint, so automated provisioning requires direct use of the REST API. Deprovisioning via the UI means setting accounts to Inactive and manually auditing group memberships - neither step triggers the other automatically.
Bottom line
RelativityOne's manual user management is functional but operationally intensive at scale. Every app and workspace requires explicit group assignment, there is no bulk import path, and deactivation does not clean up group memberships.
Teams with low user churn and few workspaces can manage this manually; teams with higher volume or compliance-driven access review requirements should plan for API-based automation from the start.
Automate Relativity 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.
