Users, Roles and Permissions in a Review Database

There are no user licenses in DISCO. You may create an unlimited number of users for your review databases.

Adding a new user to a review database

Only organization and/or review administrators can add users to a review database.

1. On the DISCO home page, in the main menu, click Review Team.
   

2. On the Review Team page, click in the Assign or invite a user... text box and select a user from the list or click Invite new user to create a new user. Then, choose a role for the user in the role dropdown (custom roles are available as well):

   

   

   • Admin – The admin role may complete all actions in DISCO.
   • Reviewer – The reviewer may complete searches, complete batch actions such as mass tag and exhibit sets, set up and manage stages, and produce documents from DISCO as well as review documents inside and outside of Review Stages.
   • Restricted Reviewer – The restricted reviewer does not have access to the usual DISCO features of search, batch actions, and productions. They only have access to the stages for which they have been assigned. In the document viewer, restricted reviewers will have access to view related documents (such as families, conversations, and similar documents). However, if a related document is not in one of their assigned batches, the restricted reviewer will not be able to perform any action on the document; they will only be able to view these related documents for purposes of context in their review.
3. When you add a restricted reviewer to a stage, they will receive a welcome email instructing them how to log in to the database and start reviewing, and they can then check out batches and review documents.

Managing existing users in a review database

Only organization and/or review administrators can manage users in a review database.

You can delete a user or update their role. If you want to change the user's email address, you must delete the user and add them again.

1. On the DISCO home page, in the main menu, click Review Team.
   
2. On the Review Team page, next to the user you are editing, either click in the Change Role dropdown to select a new role, or click the X to delete the user.
   
   Your changes will be saved automatically.

Creating a custom role

Only organization and/or review database administrators can create or edit custom roles in a review database.

1. On the DISCO home page, in the main menu, click Review Team.
   
2. On the Review Team page, click the Roles tab.
   
3. In the CUSTOM ROLES section, click New custom role.
   
4. In the Role name text box, enter the name of the new role, and then click Create Role.
   
5. Select and deselect feature permissions, work product permissions, and default document access to customize how much a user with that role can view and manage different parts of the application.
6. To create a rule, under Rules, click Create a new rule.
   
7. In the New Rule dialog, select the conditions for the rule and then click Save.

Here are a few examples how the permissions are managed and what impact it has on review database access.

Term Highlights

Term Highlights permissions can now be set to (i) Manage, (ii) View, or (iii) not viewable (Unchecked) in the Feature Permissions / Setup section of the Roles page.

A new permission, View Global Highlights, has been added. This separate permission controls whether global term highlights appear when viewing a document in the document viewer. Turning these off may be helpful when setting up a role for an expert reviewer, for example. This permission was previously briefly included beginning in September 2023 as part of the Term Highlights permission in the Setup category of feature permissions, and has now been broken out into its own permission, as seen below in the Document Viewer category.

Note: "Search hits" highlighting, which generates from keywords currently in a user's search bar, will still operate even if the View Global Highlights permission is turned off. There is not a permission associated to highlighting hits from a user's active search, beyond choosing the color of the highlighting, which is selected in the term highlights management screen.

In the below example, the word "data" is set up as an orange highlight, but this user's role is Unchecked for the Term Highlights permission. Access to the management screen is locked.

Continuing with the same example, the user's role is Unchecked for the View Global Highlights permission. The highlights do not appear in the document, and the global highlights section does not appear in Jumper. Because the user has access neither the Term Highlights permission nor the View Global Highlights permission, the user is not aware that "data" is a global highlight.

A user with the View permission for Term Highlights will be able to access the term highlights management page, but will only be able to view the lists of highlighted terms. The lists are not editable for that user. This user has also been given the View Global Highlights permission; when viewing a document, the terms will highlight on the document, and the highlights will be navigable via the global highlights section in Jumper.

In the below screenshots, the user's role is set to View for both the Term Highlights permission and the View Global Highlights permission.

Finally, a user with the Manage permission for Term Highlights will be able to add/delete in the global highlighting in the database, and can also set the color for each group of highlights.

In the below example, the user's role is set to Manage for Term Highlights.

Saved Searches

Saved Search permissions can now be set to (i) Manage, (ii) View, or (iii) not viewable (Unchecked) in the Feature Permissions / Explore section of the Roles page.

A user without any permissions for saved searches (Unchecked) will neither be able to access the saved searches menu in the search bar, nor be able to save searches. That user also will not have saved searches available as an option to add within the search builder. However, please note that search history is still accessible and usable. This is because search history is not shared between users--it is entirely personal for each user.

Unchecked (no permission): cannot open the saved search menu:

Unchecked: cannot save searches:

Unchecked: no access to nest searches within search builder (the cursor is hovering over an area that otherwise would have a "saved search" button):

A user with the View permission is able to access and run saved searches. That user is also able to save searches, and can manage any saved searches which she created (i.e., editing the saved search, editing its name, and moving it within any organizing categories in the saved search menu). The saved search option is also available for nesting searches via the search builder.

View: can see and run saved searches:

View: can save searches:

View: cannot edit saved searches that were created by other users. A different user saved the "pricing v1" search, so it is shown with the lock icon here.

View: can edit their own saved searches:

View: can organize their own saved searches:

View: can nest searches inside of another search in the search builder:

A user with the Manage permission is able to access and run all saved searches. Additionally, that user able to save searches, and can manage all saved searches regardless of who created the saved search. The saved search option is also available for nesting searches via the search builder.

Folders

Folders in DISCO have two overall setting levels for permissions. One setting level is applied on a per-folder basis, allowing permissions to be set at a very granular level from the folders setup page. However, folder permissions can also be controlled en masse, from within the roles page. Importantly, the more restrictive rule will be the controlling rule. So if a folder has been set to be accessible to everyone, but a user is in a role which only has an access level of "view" from the roles page, then that user will not be able to add or remove documents to/from that folder.

Managing folders individually from the Menu / Folders page:

Accessing folders from the Menu / Folders page:

The Menu / Folders page can have access removed via the roles permission named Folders in the Feature Permissions / Setup section. This permission removes access to the folders management page, but does not remove access to the folders themselves, nor does it remove access to the documents within the folders.

In addition to the Feature Permissions / Setup / Folders permission, there is another important location for controlling access to folders: Default Work-Product Access / Folders, as pictured below. This setting will control the ability to view and edit folders en masse; a more restrictive setting here, such as unchecking the view option, will override generous permissions that may have been applied to specific individual folders. This does not remove access to any documents.

Fields

Custom fields (which can be applied during ingest or through DISCO's overlay capability) can now also be controlled to remove view access. Removing view access to these fields will remove them from being available in DISCO's search builder, will remove them from being populated columns in a custom view in the document list, and will also remove them from the metadata panel in the document viewer.

Note that this only applies to custom fields. The default "system fields" storing the metadata extracted from documents during processing, such as email sender, create date, etc., are not affected by this permission setting. Remove access to them by unchecking the boxes for Fields in the Default Work-Product Access section, as seen below.

Annotations

Annotations can be set to be editable, view-only, or not viewable for a user role. This will apply to all annotations in the database. If annotations are set to be not viewable for a user role, then users in that role will not be able to do the following: view annotations, navigate between them in the document viewer via the jumper (top right panel), include annotation information in a column in a custom view, include annotation information with search builder, access annotation information in the filters panel, or include annotations in a batch print.

If you are setting up a user group to not be able to view annotations, then we also advise removing access to View Document History in the settings in Feature Permissions / Document Viewer. We also advise removing the permission for Feature Permissions / Setup / Annotation Reasons.

In the below pair of screenshots, notice the differences for the same document being viewed under two different permission levels: the annotations panel on the left is locked; the jumper does not include an annotations line; and the annotation box does not appear on the document image.

Annotations access level is set to Not Viewable:

Annotations access level is set to Editable:

Document and Privilege Notes

DISCO's default Document Note and Privilege Note fields can be set as editable, view-only, or not viewable. Setting these note fields as not viewable will result in their panel being inaccessible in the document viewer, their fields not being addable via the search builder, and their information not being available in columns in custom views.

If you are setting up a user group to not be able to view document notes and privilege notes, then we also advise removing access to View Document History in the settings in Feature Permissions / Document Viewer.

Redactions

Redactions can be set to be editable, view-only, or not viewable for a user role. This will apply to all redactions created in the database. If redactions are set to be not viewable for a user role, then users in that role will not be able do the following: view redactions, navigate between them in the document viewer via the jumper (top right panel), include redaction information in a column in a custom view, include redaction information within search builder, access redaction information in the filters panel, or include redactions in a batch print.

If you are setting up a user group to not be able to view redactions, then we also advise removing access to View Document History in the custom role's settings in Feature Permissions / Document Viewer. We also advise removing the permission for Feature Permissions / Setup / Redaction Reasons.

Important: redaction permissions do not affect the availability of redactions when producing documents. Documents will still be redacted by the production system. Documents produced from DISCO will also have production images included in the document viewer, so if the document was produced with redactions, those redactions will be visible on the Bates-stamped production image.

In the below pair of screenshots, notice the differences for the same document being viewed under two different permission levels: the redactions panel on the left is locked; the jumper does not include a redactions line; and the redaction box does not appear on the document image.

Redactions access level is set to Not Viewable:

Redactions access level is set to Editable:

If you are uncertain how to configure user role permissions to meet your needs, remember that you can contact your Project Manager on DISCO's Services team, or you can also reach out to DISCO Desk support at discodesk@csdisco.com.