Client domains

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

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:

  • Shared resources - many resources are completely shared between client domains. For example, the web, agent, SQL, and processing servers are shared between all client domains in an environment by default, although administrators can manage workspace SQL servers and agent servers if resource segregation is required.
  • 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.
      Notes: We only allow the creation of 10 Client Domain Utility servers. Any client domain created after the first ten Client Domains are out of the scope for Utility Servers. There is security around the Client Domain's UVM file servers that limit this from working. Only the first 10 created Client Domains can have a UVM, and then none thereafter. This is true even if some of the first 10 created do not have a utility server, we still cannot create a utility server for the ones past the initial 10.
  • 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, publish, and errors.
  • Import data.

Client domain admin considerations

Consider the following when assigning a client domain admin:

  • Client domain admins cannot perform tasks that are exclusive to Relativity System Administrators.
  • Client domain admins do not have access to Mass Operations on the Users tab.
  • 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 permissions for importing / 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 sys 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.

Note: Do not change Client Domain Admin Permissions in any way, unless instructed by the support team. This will allow a user to view other user groups in the instance. If you have changed these permissions, support@relativity.com 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 (e.g., 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> View Error View
Client Domain Admin for <Client> Add Error Add
Client Domain Admin for <Client> Edit Error Edit
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

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.

  1. Navigate to the Groups tab.
  2. Select the client domain admin group.
  3. Click the Add button in the Users section.
  4. Select the user you want to be the client domain admin.
  5. 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):

  • Multi-tiered client domains - an enabled Client Domain cannot have their own sub/child client domains
  • the 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 request to 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.

  • 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

ARM is 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

Remote Processing Console (RPC)

RPC is not available to Client Domain Admins.

No access

Has access

SFTP for Data Transfer SFTP is not available for client domain users. No access Has access
Sandboxes RelativityOne Sandboxes do not support client domains functionality. N/A N/A
Store RelativityOne Store will not be available as a storage option for client domains. No 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

Workspace Portal

The Workspace Portal tab is not be accessible by default to client domain users.

Permissions to view this tab can be 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, 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: