Permissions scenarios

In this topic, you can explore various scenarios that involve managing permissions.

See the following related pages:

• Setting instance permissions
• Setting permissions on objects
• Preview security
• RelativityOne Security Center
• Security Alerts

Hierarchical structure

System administrators have the highest level of managerial rights followed by workspace administrators. Standard users have limited administrative capabilities and primarily operate within the permissions assigned to them.

• System administrators—have the highest level of administrative rights with broad access to system settings, configuration, and management functions. Their permissions and rights supersede those of other user roles. They can control the overall system behavior, user management, security settings, and other administrative tasks.
• Workspace administrators—have administrative control over specific workspaces. They can manage settings, configurations, and security within their assigned workspaces. Additionally, they can modify object permissions, manage users and groups, configure layouts, and perform other workspace-specific administrative tasks.
• Standard users—do not have administrative privileges and cannot modify system or workspace settings. They are only allowed to access and interact with objects based on the permissions assigned to their user accounts or the groups they belong to.

Client domains

In the hierarchical structure of permissions, client domain permissions are positioned below system administrators but above workspace administrators and standard users. This arrangement facilitates the delegation of administrative tasks to a specific user group known as client domain admins. Unlike the System Administrator group, client domain admins have limited visibility and control confined to their designated client domain. This isolation feature ensures more precise administrative control over a defined segment of the environment, preventing unauthorized access or changes to the overarching RelativityOne instance.

Client domain admins possess the flexibility to adjust permission settings for various objects within their domain, customizing them to align with their specific preferences. However, these permissions are restricted solely to their allocated domain and do not extend beyond it. This protective measure guarantees that they cannot access or modify permissions beyond their designated client domain. By implementing client domain permissions, system administrators can proficiently oversee their domain while upholding the integrity and security of the broader Relativity environment.

Note: Violating the boundary of client domains in a system like Relativity can lead to significant risks and consequences, affecting data security, compliance, and overall system integrity. Client domains serve as isolated environments within the system, providing each client with a segregated space to manage their own data and operations independently.

User groups

User groups serve as a means to organize and manage users who share similar roles or permissions. You can assign user groups at either the workspace level or the system level, based on the intended extent of access and management. When assigned at the workspace level, user groups pertain to a particular workspace, governing the permissions and access rights within that workspace. On the other hand, at the system level, user groups have wider-ranging implications and can influence permissions and access across multiple workspaces within the Relativity environment.

Template groups

Template groups can play a crucial role in efficiently copying over permissions. Template groups allow you to define and configure sets of permissions that can be applied to multiple workspaces or objects. You can create template groups to encompass specific permission settings. These can include object-level and item-level security, document-level security, and field-level security.

These templates provide predefined sets of permissions that can be applied to new workspaces. User groups can be added or removed from specific security workspace templates, allowing for granular control over access and permissions based on the needs of each template. This enables administrators to tailor the security settings for different types of workspaces. This guarantees users are assigned to appropriate groups with the necessary permissions for their roles.

Review templates

Use Review templates for the review phase of a legal case or investigation. They provide tools and features for document review, coding, tagging, and production.

There are four main customizable Review Template groups:

1. Level 1 Reviewer:
   • Allowed to view and apply tags to documents.
   • Mark documents as ‘responsive’ or ‘privileged’ for case relevance to help categorize and classify.
2. Level 2 Reviewer
   • All permissions of a Level 1 Reviewer.
   • Add and edit tags.
   • Able to redact sensitive and confidential information.
   • Apply highlighting to sections of a document.
   • Ability to add annotations or comments in a document.
3. Attorney Reviewer
   • All permissions of a Level 2 Reviewer.
   • Create and modify saved searches.
   • Mass operations capabilities.
   • Create and manage redactions and annotations.
   • Access reporting features for analysis and Import/Export documents.
4. Administrator Reviewer
   • All permissions of an Attorney Reviewer.
   • Manage review workspace settings like creating user accounts and groups.
   • Configure fields.
   • Setting up searches and saved searches.
   • Configure security settings.
   • Manage review batches and workflow assignments.
   • Customize layouts.

Investigation templates

Investigation templates are designed for conducting investigations and offer functionality for evidence management, interview coordination, case progress tracking, and report generation. Unlike Review templates that primarily concentrate on document review and tagging, Investigation templates prioritize broader facets of the investigative process and include several key functionality:

1. Case Management—investigation templates offer tools to track and manage case-related information, including key dates, participants, and case notes.
2. Evidence Tracking—these templates track and help organize evidence which allows investigators to associate documents, interviews, and other artifacts with specific cases or subjects.
3. Interview Management—investigation templates may include features to manage document interviews conducted during the investigation, which can involve capturing interview transcripts, tagging key information, and linking them to the relevant case or subject.
4. Data Analysis—graphs can provide data analysis and visualization which allows investigators to identify patterns, connections, and trends within the collected data.
5. Report Generation—there are reporting capabilities in Investigation templates which allow comprehensive summaries of the investigation’s findings, supporting documentation and relevant insights.

Early case assessment (ECA) templates

ECA templates focus on the initial assessment of a case or investigation. They provide tools for data ingestion, indexing, searching, and analysis to quickly identify key information used to make informed decisions. Here are some ways ECA templates differ from others:

1. Purpose—they are specifically designed to evaluate large volumes of data or information at the early stages of an investigation and quickly identify and rank relevant information, assess the merits of a case, and make informed decisions regarding further actions.
2. Data Volume and Complexity—ECA templates can handle large and complex datasets commonly found in cases. They offer mechanisms for efficient data ingestion, indexing, and searching across various sources, such as emails, documents, and electronic records. In contrast, review templates and investigation templates may not necessarily deal with such extensive data volumes and may have different mechanisms for data organization and analysis.
3. Time Sensitivity—ECA templates aim to expedite the initial assessment of a case or investigation, taking into account time constraints and the necessity for rapid decision-making. They strive to pinpoint critical information, potential risks, and key players early in the process to steer subsequent actions. While review templates and investigation templates might involve longer timeframes and more intricate procedures to facilitate comprehensive analysis and evaluation.
4. Early Case Strategy—ECA templates often incorporate features that allow legal teams to develop an early case strategy based on the initial assessment. This includes identifying key issues, potential legal theories, and relevant documents or evidence that may impact the case.
5. Legal Compliance and Privilege Considerations—ECA templates need to address legal compliance requirements and considerations for maintaining attorney-client privilege and work product protections. They may provide features to flag privileged information, conduct privilege review, or track legal holds on relevant documents. Review templates and investigation templates may have different compliance requirements depending on the nature of the review or investigation.

Security workspace templates

With Security workspace templates, you can establish a secure environment within Relativity. Using these templates, you can define access controls, manage user permissions, and ensure data security within the workspace.

Object-level permissions

You can employ object-level security to restrict entry to specific documents or items within the workspace. These objects encompass various components such as workspaces, documents, fields, and other elements within the system.

Tailoring access to these objects can be done on an individual user or group basis. User access determines the extent of permissions and actions a specific user can perform. Group access simplifies the management of permissions for a set of users in the same category. By managing user or group access, you can determine who is authorized to view, edit, or carry out specific actions on the objects within the system.

Furthermore, objects can have document-level or field-level permission configurations. Document-level permissions allow you to control access to individual documents based on user roles or specific criteria. Similarly, field-level permissions offer the ability to regulate access to particular fields within a document. You can set restrictions on who is permitted to view or modify specific fields based on user or group permissions.

Item-level permissions

Item-level permission settings allow you to:

• control access to individual documents in a workspace. You can review, and potentially change, item level security settings when adding a group to objects with override security to guarantee that access is appropriately restricted.
• define what groups or users can view, edit, delete, or perform other actions on individual documents. You can set permissions at a granular level to guarantee only authorized individuals have access to specific documents.

When the system determines access to an item, it first evaluates the workspace-level permission settings. Then it takes into account any item-level permission settings. If there's a conflict between item-level permissions and workspace-level permissions, the system enforces the more restrictive one.

To change item-level permission settings, you must navigate to the specific document or object and make changes individually.

Document unitization

The Document unitization solution allows users to split imaged documents into many child documents. This solution consists of several components, including the Relativity application, dynamic objects with associated object rules, event handlers, manager and worker agents, and views and layouts on the Document object.

To use the Document unitization solution, users must have the following permissions:

1. View and edit permissions on the Document unitization layout—users need these permissions to access and modify the unitization settings for documents.
2. View permissions on the Document Utilities object—users who need to see the status of unitization jobs or requests should have view permissions on the Document Utilities object.
Note: If you enable document item-level security and overwrite security on document folders, the relevant groups must possess Add Document and Add Images permissions per folder.

Important considerations

Take the following into consideration when using document unitization solution:

• Unitization only works on imaged documents, not native documents.
• During unitization:
  • Relativity tags the parent document as a parent and each child document as a child.
  • redactions from the parent document are not carried over to the child documents.
  • child documents do not receive any propagated metadata.
• You can unitize any document that has images.
• You can create multiple instances of manager and worker agents to distribute the workload.
• You cannot:
  • unitize child documents further.
  • perform document unitization on a parent document currently undergoing unitization. You can verify the successful creation of all child documents by checking the Related Items pane before initiating a new unitization request.
• You can access the Document Unitization layout in the mass edit drop-down menu. It's important not to use it for splitting documents since the event handler framework does not execute from the mass operation framework.
• You need to install the Document Unitization solution in at least one non-administrative workspace to confirm the agents remain active in the environment.
• Document Utilities is a Relativity application that contains two solutions: Move to Folder (a mass operation) and Document unitization. Installing the Document Utilities application automatically installs the Move to Folder mass operation.

Deployment and configuration

Note: The solution does not process any data in a workspace if the associated resource pool does not have its own manager and worker agents. In such cases, document unitization jobs will remain inactive in the queue.

Do the following to deploy and configure document unitization:

1. Add the Document Utilities application to the Application Library as a Relativity application.
2. Install and configure the Document unitization solution in the desired workspace.
3. Create at least one manager agent and one worker agent. You can generate multiple instances of these agents to distribute the workload.
4. Create the manager and worker agents on each instance of the agent server associated with the resource pools used in workspaces where the Document unitization solution will be used.
Note: Document Unitization processes approximately 500 jobs per hour.

Scenarios

Additive permissions and Staging Explorer across workspaces

Setup:

You have two groups, Group A and Group B, and two workspaces, Workspace 1 and Workspace 2.

Group A has permission to use Staging Explorer, and permission to access Workspace 1. This is your typical Client Domain Admin group.

Group B has permission to access Workspace 2. This is a typical Review group.

If a user is in both Group A and Group B, they have three permissions:

• Permission to use Staging Explorer, which is an instance-wide permission.
• Permission to access Workspace 1.
• Permission to access Workspace 2.

User Groups	Permissions	Access to Workspaces
Group A (Client Domain Admin)	Use Staging Explorer (instance-wide permission)	Workspace 1
Group B (Review)	Access to Workspace 2	Workspace 2
User in both Group A & B	Use Staging Explorer (instance-wide permission) Access Workspace 1 & 2	Workspace 1 & 2

Note: In this case, because permissions are additive, and if the StagingPaneOnlyPerClientDomain setting is set to False or missing, a user in both groups can use Staging Explorer to access the files on file shares for both Workspaces 1 and 2, even though neither group explicitly gives permissions to use Staging Explorer on the Workspace 2 file share. For more information regarding this, see the Permissions section of the Staging Explorer

Frequently asked questions