User Groups and Project Permissions

Table of Contents

On Everlaw, project permissions control access to features and tools within projects. These tools include codes, assignment groups, and StoryBuilder objects (e.g., Chronologies, Outlines). By contrast, the permissions governing document uploads, document deletions, and project creation are called database permissions. This article will focus on project permissions on Everlaw. To learn more about the difference between project and database permissions, please read this articleFinally, although there is currently no way to restrict users' access to documents within the same project, you can restrict users' access to documents by creating separate projects. Please read this article for more information. 

Because project permissions are assigned to groups of users, this article will begin by walking through group creation. Next, we will discuss configuring project permissions for user groups. Finally, we will discuss how different project permissions interact with each other, and how permissions are assigned to new features on Everlaw.

To learn how to add users to projects on Everlaw, see this help article

 

 

Groups

On Everlaw, project permissions are granted to user groups, rather than individual users (though a group could consist of an individual user). If a user is in multiple groups, their permissions will be a combination of both groups’ permissions, always favoring the least restrictive permission option.  

By default the Administrators and Reviewers groups are included with all new projects. However, you can easily create a new group with custom permissions for your project. In order to create a new group, you must be a project admin. In addition to other aspects of project management, project admins manage users and user groups on Everlaw projects.

To get started creating new groups, navigate to the Project Settings page. You can get here by clicking the Project Navigation icon in your upper right toolbar and choosing Project Settings.

 Screen_Shot_2019-01-11_at_6.03.07_PM.png

The Project Settings page is your control center for project administration. To manage your user groups, click the Groups tab on the left hand sidebar of the Project Settings page.

Screen_Shot_2019-01-11_at_6.05.43_PM.png

You will see the Administrators and Reviewers groups, which are included on your project by default. You can add existing users to these groups via the dropdown. 

Add_users.gif

If you would like to keep these default groups, but view and edit their permissions, you can click the three-dot menu to the right of the group name and then choose “Project Permissions.” If you would like to delete this, or any group, you can choose “Delete group” from the menu. You will also be able to access and edit the objects a group has permission to by selecting “Object permissions.” 

The rest of this section, however, will walk you through how to create a new group on Everlaw.

From the Groups tab, click Create Group in the top right corner. A dialog box will open, showing you the possible templates you can use to configure the group’s permission settings.

create_new_group.gif

You will first see Everlaw templates, which contain preset permission configurations based on common roles during review. For example, the Case Leads template gives users in the group the ability to access and utilize most tools on the project, but does not give them administrative rights across the entire project. You can also use an existing group on your project to form the basis of the new group’s permissions by choosing “Create new group using an existing group’s permissions” at the top of the dialog box. New groups that you create will be added to this list for future use. 

Once you’ve chosen the starting point of your group’s permissions and named the new group, click Create.

Return to table of contents

Configuring project permissions

To view your group’s permissions, either choose “Modify permissions” in from the group’s three-dot menu, or click the Permissions tab on the left sidebar. Then, use the dropdown menu to select the desired group.

Screen_Shot_2019-01-11_at_6.15.44_PM.png

The permissions tab shows you a detailed view of the group’s permissions organized by functionality type. Please note that you can also view a group’s permissions in a table view by toggling the Table View button in the top right corner of the permissions tab. 

 table_view_permissions.gif

Table view.

This article, however, will walk through the permissions tab in Detailed View.

Everlaw_Permissions_Interface.png

Detailed view.

At a glance, you can tell what levels of access the group has by the color of the section headers in the detailed view of the permissions tab. A green header indicates that the group has access to every tool in the section. A yellow header indicates that the group has access to some tools in the section, but no access to others. Finally, a grey header indicates that the group does not have access to any tools in the section.

For a complete list of project permissions on Everlaw, please see the permissions table at the end of this article.

Different project permissions have different types of permission settings. Some permissions operate on an all-or-nothing basis. These permissions are set via checkbox, and user groups will either get full access to the tool or no access to it. For example, the Document Export section has four permissions, all of which have two settings: Full access (checked) or no access (unchecked).

Screen_Shot_2019-01-11_at_6.20.49_PM.png

Other permissions have multiple levels of access you can grant the user group. In general, these different permission levels range from None to Admin. Let’s look at the Search Term Report as an example, keeping in mind that other tools, such as assignment groups, prediction models, and StoryBuilder have similar permission levels. Search Term Reports has four permission levels: None, Receive, Create, and Admin.

 Screen_Shot_2019-01-11_at_6.21.41_PM.png

None: Users in the group will not be able to create search term reports, nor will they be able to receive search term reports shared by others.

Receive: Users in the group can receive search term reports from others, but cannot create search term reports themselves. When a search term report is shared with a user in this group, the user can be given View, Edit, or Share and Delete permissions on the individual search term report.  

Create: Users in the group can create their own search term reports. Permission levels on Everlaw are additive, so groups with the Create permission are also able to receive search term reports shared by others.

Admin: This is the highest permission a group can have on search term reports. Users in groups with admin permissions on search term reports are able to view, edit, and share and delete all search term reports in the project, regardless of whether the owner has shared it or not.

If you revoke a group’s ability to receive an object type, and they’ve already been shared an object(s) of that type, you can choose to maintain or revoke permissions on those objects for the group. Let's use our current example to illustrate. 

If a project admin changes the Receive, Create, or Admin permissions on an object type to None, they will be presented with two options for objects the group already had access to. Either (1) revoke group permissions on all objects of that type or (2) allow the group to maintain their existing permissions only on those objects.

For example, a group with Create permissions on search term reports has their permissions downgraded to None. If you select ‘Revoke existing permissions’, then that permission group will lose all access to search term reports, including any search term reports they had access to previously. If you select “Allow the group to maintain…”, then they will maintain access to the search term reports they currently have access to, but will be unable to receive or create any more search term reports. In either situation, they may maintain access to these objects through other sharing, since they had Create permissions. If a user has no other access to an object class after this change, then the decision will affect their individual object permissions as well.  To learn more about accessing objects please visit this article on sharing or read on to the individual user permissions section. For a complete list of project tools and their permissions, please see the table at the end of this article.

For a complete list of project tools and their permissions, please see the table at the end of this article.

Return to table of contents

Code and rating permissions

Everlaw makes it easy to assign permissions on codes, whether you’re assigning permissions on codes across the project, across a coding category, or by individual code. The three permission levels for codes and ratings are None, View, and Apply. Please note that only project admins can edit the names of codes, or delete them from the project entirely.

Screen_Shot_2019-01-11_at_6.23.36_PM.png

None: Users in the group have no access to the code. They cannot view, search for, or apply the code to any documents.

View: Users in the group can view and search for the code on documents, but they cannot apply or remove the code from documents.

Apply: Users in the group can view, search for, apply, and remove the code from documents. Any group can receive the Apply permission on codes.

To apply the same permission to all codes in the project, click the dropdown next to All Codes and select a permission level.

 Screen_Shot_2019-01-11_at_6.24.34_PM.png

You can also expand the Categories and Codes section to display all categories in your project. To apply the same permission to all codes in a category, click the dropdown next to the category name. Then, select a permission level.

If you expand the category to display the underlying codes, you can assign permissions to individual codes, as well. If some codes in a category have different permissions than other codes in the same category, the category dropdown will say “Custom.”

 Screen_Shot_2019-01-11_at_6.25.25_PM.png

Please note that if you create a user group prior to adding any codes to your project, the group will automatically receive Apply permissions on any codes you subsequently create. You can later change code permissions for the group once the code has been created. 

If a new code is added to a project with existing codes, the new code’s permission level will reflect the highest permission that the group has on other codes in the same category. For example, if a new code is later added to the “Production Designations” category (shown below), this group would automatically receive View permissions on the new code, because that is the highest existing permission on a code in that category.

Screen_Shot_2019-01-11_at_6.27.14_PM.png

If a new category is added to a project with existing codes, the permissions for that category’s codes will reflect the highest permission that the group has on any other code in the project. In other words, if the group has View or Apply permissions on at least one code in the project, all codes in the new category will reflect the same permission.

Return to table of contents

User field permissions

User fields have similar permission levels to codes, though the highest permission is Edit, rather than Apply. The Edit permission allows users in the group to search for, view, and add and remove field values to documents.

One thing to note about user field permissions is how they affect metadata aliases. Aliases combine multiple metadata fields under one name for consolidated searching and viewing. You can create metadata aliases out of document metadata, as well as user metadata fields. If a group has None permissions on at least one user field underlying an alias, the users in that group will not be able to view, search for, or edit that alias.  

Return to table of contents

Permission dependencies

Certain features and tools on Everlaw require access to specific parts of the platform for optimal use. For example, in order to view most aspects of project analytics, it is necessary to also be able to view ratings. Therefore, granting certain permissions will require that other permissions are also granted.

analytics_dependency.gif

The below table lists the permissions which require additional permissions.

The following permission:

Requires, at minimum, the following permission(s):

Project Admin

Full project permissions (database permissions not required)

Productions: Share

All Codes: View; All User Fields: View

Productions: Admin

Notes and Highlights: View; Redactions: View; All Codes: View; Ratings: View; All User Fields: View

Analytics

Ratings: View; All Codes: View

For more information about project permissions, or to learn how to grant database permissions, please see our documentation linked below. If you have any questions, please feel free to contact us by message, email or phone.

Return to table of contents

Individual user permissions

You can view the project and object permissions of any user on your project by navigating to the Users tab on the Project Settings page. Then, click the list icon in the Perms. column of the user. 

Screen_Shot_2019-06-28_at_4.49.19_PM.png

The first tab will show you a list of the user's project permissions. If you are also a database admin, the user's database permissions will be listed here, as well.

The second tab will show you a list of the different objects that a user has access to. Within this dialog you can revoke a user’s access to various objects.

The dialog will show you a list of the user's project permissions. If you are also a database admin, the user's database permissions will be listed here, as well. 

Return to table of contents

Future features

New features are regularly added to Everlaw, some of which may be released with their own permissions. To save project admins time when we release new features, we automatically grant permissions on new features in accordance with each user group’s existing permissions on related features. For example, if a new feature is closely related to redactions, groups who have Admin permissions on redactions will be granted permissions related to the new feature. Project admins will always receive full permissions on new features. If a new feature permission requires existing permissions that a group does not already have (e.g., a new analytics feature that depends on access to ratings, but the group currently does not have access to ratings), then the new permission will never be granted to that group. In other words, we will never automatically expand a group’s current permissions to accommodate a new permission requirement.

Return to table of contents

List of project permissions on Everlaw

Below is a complete table of project permissions on Everlaw:

Project permission

Description

Project Admin

Administrative access on all project permissions; create and administer users and groups, categories and codes, user fields, and metadata; perform all actions on the Project Settings page; view user activity and email threading; resolve rating conflicts.

Partial Project Document Management (only on partial projects)

Add documents to, or remove documents from, the partial project.

Search Term Reports

None: No access to search term reports;

Receive: Receive shared search term reports;

Create: Receive and create search term reports;

Admin: Admin access to all search term reports in the project.

CSV Export

Export document data to CSV

PDF Export

Export documents and metadata to PDF

ZIP Export

Export documents, load file, and review work to ZIP

Document Download

Download and print documents

StoryBuilder

None: No access to any StoryBuilder objects (e.g., outlines, chronologies);

Receive: Receive all shared StoryBuilder objects from other users;

Create: Receive all StoryBuilder objects and create outlines (chronologies must be created by project admins);

Admin: Admin access to all outlines, and “Share” permissions on all chronologies in the project.

Productions

None: No access to the Productions page. All users can search for and view documents that have been produced;

Share: Download and share all productions;

Admin: Create, modify, download, and share all productions.

Analytics

View and manage project analytics

Prediction Models

None: No access to any prediction models;

Receive: Receive shared prediction models from other users;

Create: Receive and create prediction models;

Admin: Admin access to all prediction models in the project.

Document History

View document history for all users in the review window

Batch Updates

Apply batch actions to documents from the results table

Context Panel Updates

Update documents from the review window context panel

Auto-code Override

Override auto-code rules for coding actions

Unitization

Unitize documents from the review window context panel

Assignment Groups

None: No access to assignment groups. All users can receive individual assignments.

Receive: Receive shared assignment groups from other users;

Create: Receive and create assignment groups;

Admin: Admin access to all assignment groups in the project.

Redactions

None: No access to redactions applied prior to production. All users can view redactions that have been burnt in during production;

View: View all redactions and redaction notes;

Create: View and create redactions and redaction notes, but only modify those which the user created;

Admin: Admin access to all redactions and redaction notes.

Notes and Highlights

None: No access to notes or highlights;

View: View all notes and highlights;

Create: View and apply notes and highlights, but only modify those which they created. Create notes on batch redactions (with proper Redactions permission);

Admin: Admin access to all notes and highlights in the project.

Ratings

None: No access to document ratings;

View: View all document ratings;

Apply: Apply and remove document ratings.

Categories and Codes (permissions apply to individual codes)

None: No access to the code;

View: View and search for the code on documents;

Apply: Apply and remove the code from documents.

User Fields (permissions apply to individual user fields)

None: No access to the user field;

View: View and search for the user field (must have View permissions on all fields in an alias to view and search against the alias);

Edit: Edit values for the user field.


 

Return to table of contents

Have more questions? Submit a request

0 Comments

Article is closed for comments.