

The client domains feature enables Relativity to deliver more powerful managed service offerings for service providers in a single Relativity
Using client domains, system admins can empower a user group that is not part of the System Administrator group, client domain admins, to perform common administrative tasks within their own client domain while limiting their visibility into the Relativity environment as a whole. The client domain admins can customize the permission settings to various objects according to their preferences within their own domain, but cannot access any permissions outside of that. This resource isolation functionality grants your enterprise clients more administrative control over their own portions of the environment while preventing back-end visibility and unauthorized changes to your Relativity
Note: Client domains are targeted for the above use case only and it is important to consider all the limitations outlined in
Implementing client domains requires an additional license from Relativity ODA LLC. Each client domain license is unique, and client domains can have different terms encoded on their license keys. The license for a client domain is unrelated to any other license for Relativity (e.g., number of seats). Client domain licenses are not transferable from one client to another.
See the following related pages:
The following describes the basic software architecture for client domains.
The following information describes the architecture of the cloud infrastructure for client domains:
The following diagram shows how the above components interact.
Consider the following before enabling client domains:
Note: You cannot convert an existing client to a client domain.
To request a new client domain, you must submit a RelativityOne request via the Community site by navigating to the Support tab and then RelativityOne requests (as detailed in the following knowledge article). Please note that the Client Domain creation process takes 3 business days. If an Utility Server was requested, you will also be contacted with the following information:
The following things occur automatically after client domains are enabled:
Once client domains functionality is enabled for the client, you must assign a client domain admin.
Client domain admins are essentially workspace admins for workspaces within the client domain. Any limitations are based on the permissions you set for the user group in Relativity that the client domain admin belongs to. The administrative actions available to client domain admins are only in the scope of the client domain. For example, client domain admins can edit or delete users belonging to that client domain, but they cannot do the same action for users part of a different client domain or users not associated with a client domain.
Client domain admins can do things like:
Consider the following when assigning a client domain admin:
The following table provides a breakdown of the default instance permissions for a client domain admin:
Group | Permission | Type |
---|---|---|
Client Domain Admin for <Client> | View Admin Repository | Admin Operations |
Client Domain Admin for <Client> | Add Matter | Add |
Client Domain Admin for <Client> | Add User | Add |
Client Domain Admin for <Client> | View View | View |
Client Domain Admin for <Client> | View Choice | View |
Client Domain Admin for <Client> | Add Group | Add |
Client Domain Admin for <Client> | Add Workspace | Add |
Client Domain Admin for <Client> | Add Error | Add |
Client Domain Admin for <Client> | View Relativity Script | View |
Client Domain Admin for <Client> | View Server | View |
Client Domain Admin for <Client> | View Tab Type | View |
Client Domain Admin for <Client> | Authentication Provider* | View |
Client Domain Admin for <Client> | Login Method | View, Edit, Delete, Add |
* The View Authentication Provider permission is required for Client Domain admins to add login methods to their users. Because the Authentication Provider object is not client-bound, it is highly recommended that you apply item-level security to ensure that Client Domain admins can see only the necessary Authentication Providers.
Once you enable client domains on a client, you must assign a client domain admin.
Use the following steps to assign a client domain admin.
A system admin can make any user a client domain admin by adding them to the client domain admin group. You can tailor the permission settings of a client domain admin group the same way you manage permissions for all other groups. See Setting instance permissions for more information. See Client domain admin considerations for more information on default permissions.
The following items are features and operations that are not available when using client domains (if a feature or operation isn't listed, it is available when using client domains):
Note: In 2025, Relativity is deprecating the (Admin) Errors tab in RelativityOne. This change is part of our effort to transform the error-handling experience by making it easier to address job-specific errors as they occur at their source within your workspaces. Starting in April 2025, we'll hide the Errors tab from all production instances in a phased rollout. In July 2025, we'll permanently remove it from RelativityOne and disable the ability to read errors through the API. In October 2025, we'll prevent errors from being written through the API. For more details, see Errors tab deprecation in the Knowledgebase on the Community.
The following items are features and operations that are have limitations in client domains or can only be used or performed by top-level system admins or a Relativity staff resource.
Note: If a feature, capability, or operation isn't listed, then there are no limitations on them when using client domains. For example, Relativity Legal Hold isn't listed and has full functionality when operating client domains.
Item |
Limitation |
Client domain admin |
System admin |
---|---|---|---|
Client domains setup and configuration |
|||
SSO setup |
If the SSO provider is configured correctly, a system administrator can set up client domain user accounts to use it. |
No access |
Yes |
Client domain setup |
|
No access |
No access |
Instance settings |
Not available per client domain. |
No access |
No access |
Feature access |
|||
ARM |
Not available to Client Domain Admins. Note: ARM archives can be restored directly to a client domain.
|
No access |
Has access |
Creating / editing Relativity scripts |
Not available to Client Domain Admin.
|
No access |
Has access |
Direct SQL access |
Not available to Client Domain Admin. |
No access |
Has access |
Migrate | Migrate (similar to ARM) is supported for client domains, but migrations can only be performed by a Relativity System Admin. Migrate cannot be used by a Client Domain Administrator due to security restrictions. | N/A | Has access |
Cost Explorer | System Admins have access to the Cost Explorer, but client domains do not. | No access | Has access |
Relativity applications |
|
No access |
Has access |
SFTP for Data Transfer | Not available for client domain users. | No access | Has access |
Tabs | We recommend avoiding sensitive data in tab names. You can secure new tabs by overriding inherited security settings and applying |
Has limited access | Has access |
User and Group Synchronization application | The User and Group Synchronization application is not compatible with Client Domains. | No access | Has access |
View, edit or cancel jobs / queues |
Jobs / queue status not available to Client Domain Admins. Since client domain admins can't see or modify jobs in the queue, a system admin may need to inform client domain admins of the status of jobs they've start or if the job is still waiting in the queue. |
No access |
Has access |
Views | We recommend avoiding sensitive data in tab names. You can secure new tabs by overriding inherited security settings and applying |
Has limited access | Has access |
Workspace Portal |
The Workspace Portal tab is not accessible by default to client domain users. Permissions to view this tab can technically be granted to client domain admins. However, adding a non-admin client domain group to the necessary instance level permissions violates client domain security restrictions for this group. |
No access | Has access |
Any workspaces, users, groups,
See the following pages for more information on moving objects to and from client domains:
Why was this not helpful?
Check one that applies.
Thank you for your feedback.
Want to tell us more?
Great!