Client domains

The client domains feature enables Relativity to deliver more powerful managed service offerings for service providers in a single RelativityOne instance by providing an easier way to securely isolate users, workspaces, groups, and matters by clients.

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 RelativityOne instance as a whole.

Note: Client domains are targeted for the above use case only and it is important to consider all the limitations outlined in Client domain limitations and considerations.

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. To request a new client domain, you must submit a RelativityOne request via the Community site as detailed in the following knowledge article.

See the following related pages:

Client domains software architecture

The following describes the basic software architecture for client domains.

Permissions - the root object of a client domain is the client object in the administrative workspace. By default, groups associated with a given client only have permission to perform actions on users, groups, matters, and workspaces associated with that client, unless a system administrator has given special permission across client domain boundaries. Additionally, each client domain has an associated group known as the client administrator group. By default, members of this group can create administrative objects (users, groups, matters, and workspaces) associated with the client. This group does not have permission to interact with or view objects of these types associated with other clients.
Credentials - many services in RelativityOne, such as HTML5 conversion and RelativityOne Staging Explorer, utilize custom credentials to access resources on the client domain’s behalf. For example, a credential stored in RelativityOne is used by the conversion service to access the Relativity file repository in a secure manner.

Client domains cloud infrastructure

The following information describes the architecture of the cloud infrastructure for client domains:

Utility Server - each RelativityOne tenant can have a Utility Server, which accesses the file share for each client domain. In addition, a dedicated Utility Server may be requested for a client domain within the tenant. Please note that there is a maximum of 11 client domain utility servers allowed per Relativity instance.
File server - each client domain has a separate file share configured in the system. This share is on the same server as the file share for all other client domains and the Relativity installation as a whole, but has custom permissions and IP allow lists applied to prevent access from other client domains. The client domain file share is configured to only allow access from Relativity infrastructure, the tenant Utility Server, and the client domain-specific Utility Server.
VPN Access - All access to the RelativityOne infrastructure is performed over a VPN. Within a tenant, all clients use the same VPN client; access is limited through the credentials of the Utility Server.

The following diagram shows how the above components interact.

Considerations before enabling client domains

Consider the following before enabling client domains:

If you enable client domains on a client:
- You can't disable it on that client later.
- You can't edit the name of the client, but you can edit the Client ID number.
- You can’t delete the client.
You can add objects to a client domain after the client has client domains enabled, but it's best to verify that all objects you want to isolate within the client domain are child objects of the client. See Adding or removing objects from a client domain for more information.
If you have client domains enabled, we recommend locking down System Administrator access to only those absolutely necessary.

Enabling client domains on a client

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:

IP address to the new client domain Utility Server.
Client domain user credentials to the new Utility Server.

The following things occur automatically after client domains are enabled:

The system creates a new Everyone - [Client's Name] group and adds that group to the client domain. Only users whose client field is set to the client domain are included in the client domain everyone group. The system also removes those users from the default Relativity Everyone group. A system admin can add any users to any group regardless of client domain status.

Note: The Everyone - [Client's Name] group should not be assigned as the workspace administrator group for a given workspace that is part of a Client Domain.

The system creates a unique copy of all resource pools associated with any workspaces under the client domain.

Note: Permissions assigned to groups override client domain isolation. If a non-client domain group has permissions to see a client domain's workspace or users, then those non-client domain users in the non-client domain group can still access client domain items. Enabling client domains does not change previously configured item level security settings applied to any objects within the client domain.

The system creates a client domain admin group that permits its members to perform admin operations within the client domain.
The Billing statistics - RelativityOne - case rollup and Billing statistics - users reports include columns called Client Domain Name and Client Domain Artifact ID. These columns display client name and artifact ID when you enable client domains for a client.

Note: After enabling client domains, system administrators needing to make group or permission changes should be extra cautious and thoroughly investigate the potential impact to client domain separation before implementing any new group/permission changes.

Once client domains functionality is enabled for the client, you must assign a client domain admin.

Client domain admins

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:

Modify, add, and remove groups, users, and workspaces.
Create all workspace and admin objects across the Relativity Framework, such as matters, fields, layouts, choices, and views.
Start jobs like processing, imaging, and productions.
- Tenants have access to the full complement of the Processing features, including inventory, discovery, and publish.
Import data.

Client domain admin considerations

Consider the following when assigning a client domain admin:

Client domain admins:
- are restricted from accessing the Security Center.
- cannot perform tasks that are exclusive to Relativity System Administrators.
- do not have access to Mass Operations on the Users tab.
We recommend users review Client Domain and other Administrative type permissions for item-level security based on the workflow within your instance. Relativity recommends applying item-level security to all views for the following types within the Admin landing page, removing access from all non-administrative users:
- Authentication Provider
  Note: Client Domain specific views can be used and configured to enable Client Domain administrators to configure and view their own users more easily. Ensure you have properly reviewed and tested all relevant permissions before doing so.
- Authentication Provider Type
- Code
- Fields
- Resource Pools
- Resource Servers
Permissions assigned to groups override client domain isolation. If a non-client domain group has permissions to see a client domain's workspace or users, then those non-client domain users in the non-client domain group can still access client domain items. Enabling client domains does not change previously configured item level security settings applied to any objects within the client domain.
Users with the Manage Cold Storage Admin permission and access to the workspace can move it to or from Cold Storage.
Transferring data via Integration Points uses a standard Relativity permissions check. If a client domain admin has access to a source and destination workspace and has permissions for importing and exporting data, they can transfer data to the workspace even if it’s outside the client domain.
Relativity displays a warning message when a system admin attempts to edit or copy permissions for any group in a client domain. This warning makes the system admin aware that modifying permissions may have significant consequences. For example, changing permissions may allow client domain users to modify items outside their tenancy. The system admin can click Manage Permissions to proceed with the update or Cancel to exit the pop-up window.

Caution: Do not change Client Domain Admin Permissions in any way, unless instructed by the Relativity Support team. This will allow a user to view other user groups in the instance. If you have changed these permissions, contact Relativity Customer Support to have the permissions reset to their original configuration.

If a system admin assigns additional permissions for other Admin objects to a client domain admin (such as, Queues), the client domain admin may be able to see information for other client domains.
System Administrators should be aware of the following behavior to prevent unintentionally providing users with access to data outside their domain: If you add a user who is already a member of a domain admin group to another group that holds the Relativity Script system permission, the user will gain access to all users and groups across the entire Relativity instance. Once the user is removed from the new group, access will be restricted again to users and groups associated with their specific client.
When importing a Client Domain Admin using the Relativity User Import Application, the application automatically includes the new user in the Everyone group by default. This action can disrupt the Client Domain security settings in your Relativity instance. To address this issue, follow these steps: remove the user from the Everyone group and assign them to the client-specific Everyone group. Achieve this by temporarily switching the user to any client not linked to a domain, and then back to the desired domain client.
You can grant workspace admins within the client domain permission to edit security settings for groups within the client domain, but they can't edit permissions on groups outside of the client domain.

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.

Assigning a client domain admin

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.

Navigate to the Groups tab.
Select the client domain admin group.
Click the Add button in the Users section.
Select the user you want to be the client domain admin.
Click OK.

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.

Client domain limitations and considerations

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):

Client Domain Administrators do not have access to the Errors tab, which may impact their workflows.
UVM (Utility Virtual Machine) is not available for RelativityOne Government clients.
Multi-tiered client domains - an enabled Client Domain cannot have their own sub/child client domains.
Cost Explorer isn’t accessible within a Client Domain.
Unique logos or URLs per client domain.
Customer-managed keys (CMK)
Self-provisioning / enabling of client domains requires a request to Relativity Customer Support.

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	Cannot be setup on a Client record that already has a workspace association. There are no custom URLs created for Client Domain users. Cannot disable client domain on client once enabled. Cannot rename client once enabled. Cannot delete client once enabled. The maximum number of client domains that can be created for an instance of Relativity is 100 without a utility server (or 11 if a utility server is required for all individual client domains within a RelativityOne instance).	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. Admins can run scripts that have already been added to the workspace from the library. Admin scripts are not supposed to be run by client domain admins. These scripts should not be part of the template workspace.	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	Client Domain Admin is not able to install or upgrade Relativity applications. No support of multiple app versions. Case Dynamics, and Transcripts applications have been tested and work without issue in environments with client domains. Most applications are typically not built or tested with client domain structure or concerns in mind.	No access	Has access
SFTP for Data Transfer	Not available for client domain users.	No access	Has access
Sandboxes	RelativityOne Sandboxes do not support client domains functionality.	N/A	N/A
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
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

Adding or removing objects from a client domain

Any workspaces, users, groups, or matters associated with a client domain during creation become automatically governed by that client's domain settings. When you move an object into a client domain, you're making it a child object of the client domain.

See the following pages for more information on moving objects to and from client domains: