On Everlaw, project permissions control access to features and tools within projects. These tools include codes, assignment groups, and Storybuilder objects (e.g., Depositions, Drafts). The permissions governing document uploads, document deletions, and project creation are called database permissions. This article focuses on project permissions on Everlaw. To learn more about the difference between project and database permissions, please read this article.
This article covers:
- Creating a new user group
- How to configure project permissions and object permissions for user groups
- How different project permissions interact with each other
- How permissions are assigned to new features on Everlaw
To learn how to add users to projects on Everlaw, see this help article.
To learn about permissions in Early Case Assessment (ECA) projects, see our Early Case Assessment Databases article.
Create a group
Required permissions: Project Admin
On Everlaw, project permissions are granted to user groups, rather than individual users (though a group can consist of an individual user). If a user is in multiple groups, their permissions are a combination of both groups’ permissions, always favoring the least restrictive permission option.
By default, the Admins and Reviewers groups are included with all new projects, but you can create a new group with custom permissions for your project.
To create a new group:
-
Access the Project Settings page. Go to Project Management
> Project Settings.
The Project Settings page is your control center for project administration. - To manage your user groups, select the Groups tab on the left hand sidebar.
- Select + New group in the top right corner. The New user group dialog box opens, showing you the templates you can use to configure the group’s permission settings.
There are three options for using templates. You are able to adjust the permissions of any user group you create.
You can:- Select Empty to create a group with no permissions configured
- Use one of the 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.
- Select Create new group using an existing group’s permissions to use an existing group on your project to form the basis of the new group’s permissions. New groups that you create are added to this list for future use.
- Give your group a name in the Group name field.
- Once you’ve chosen the starting point of your group’s permissions and named the new group, select Create. This creates the new group and closes the dialog.
Delete a group
Required permissions: Project Admin
To delete any group:
- Select thee three-dot
menu for that group.
-
Choose Delete group from the menu.
Note
If any users in this group are not in any other group, you will see a warning that the user will be removed from the project and that their work product will not be preserved. Select Cancel and share the users's work product before deleting the group.
- Select Delete.
Configure project permissions
To view and edit a group's permissions, select the three-dot menu to the right of the group name and then choose Project permissions.
If you are on the Permissions tab, use the dropdown menu to select the desired group.
The Permissions tab shows you a detailed view of each group’s permissions organized by functionality type.
You can also view a group’s permissions in a table view. To do so, select the Table View button in the top right corner of the Permissions tab.
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.
-
A gray 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:
-
All-or-nothing: These permissions are set via checkbox, and user groups 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).
-
Multiple levels of access: In general, these different permission levels range from None to Admin. For example, Search Term Report has four permission levels: None, Receive, Create, and Admin.
- 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 Full access 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 change the Receive, Create, or Admin permissions on an object type to None, you are presented with two options for objects the group already had access to:
- Revoke group permissions on all objects of that type
-
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.
Administration permissions
There are three different administration permissions that can be given to a user group:
- Project Admin: This is the highest administrative permission. Users with this permission have full access to all project settings and functionality. If the Project Admin permission is assigned to a user group, the group will also automatically be given the Codes Admin and Partial Project Document Management permissions, as well as the highest level of permission across all permission categories.
-
Codes Admin: Users in groups with this permission have full administrative abilities over codes. This includes:
- Add, edit, and delete for:
- Codes and categories
- Freeform codes
- Conditional rules
- Auto-code rules
- Code as previous settings
- The highest individual categories and codes permissions:
- Create for code categories
- Apply for codes
- Edit for freeform codes.
- Add, edit, and delete for:
- Partial Project Document Management (only available in partial projects): Users in groups with this permission can add and remove documents from partial projects.
Global Object Access
When granted, Global Object Access allows users to access all objects (e.g. binders, Search Term Reports, or Storybuilder Drafts) without them being proactively shared. This is useful for admins who need reliable oversight of all work product across a project and for teams that want all members to have frictionless access to each other's work.
The permission levels are:
- None: No Global Object Access. Users can only access objects they create and those that are manually shared with them.
- View: View all objects. Edit, delete or share permission is limited those objects that have been manually shared with the relevant permissions
- Edit: Edit all project objects, but only delete or share those that have been manually shared with Full Access permission
-
Full: Edit, delete, and share all objects in the project
- This option is only available for user groups that also have the Project Admin permission selected.
Important
Granting Global Object Access permission to a user group with None permissions on Storybuilder, Search Term Reports, Assignment Groups, or Predictive Coding Models will change the permission level for this user group from None to Receive. A dialog warns you before you finalize the change.
Users in a user group granted Global Object Access have a view on their homepage called the Global view. This is where they can access all the objects that they did not otherwise have access to. Learn more about the Global view in our Homepage Views and Folders article.
Users with Global Object Access can also access all objects in the project in the same way they access any other object they have created or had shared with them, such as through search or emailed/messaged links. Their permission on the objects depends on the level of their Global Object Access permission.
Objects included in Global Object Access
- Assignment Groups
- Stories
- Storybuilder Drafts
- Storybuilder Depositions
- Binders
- Search Term Reports (STRs)
- Prediction Models
- Homepage folders
Additional details about Global Object Access
Here are a few additional details to consider when granting and revoking Global Object Access:
- A user group must have Full document access to be granted Global Object Access
- By default, Global Object Access is set to None for all user groups in all projects. This is different from other project-level permissions, in which Project Admins are granted access by default.
- The settings for Global Object Access permission can be carried over with a project template
- Global Object Access is not available in ECA projects, but it is available in the Review project(s) of ECA-enabled databases
- There is no indication on an object to signify whether it is accessible via the Global Object Access permission. Users will not be notified when their objects become accessible via this permission.
- If the permission is switched from View, Edit, or Full to None, or if a user is removed from the user group where it’s enabled, then that user or group will immediately lose access to any objects that were not already manually shared with them. The Global view will be removed from their homepage.
Code and rating permissions
You can assign permissions on codes at whatever level of granularity is desired: for the entire coding sheet, across a coding category, or by individual code. To learn more about codes, please see our article Administer Codes for Review.
There are four permission levels that can be assigned to code categories and codes:
- None: Users in the group have no access to the category or code. They cannot view, search for, or apply the category or code to any documents, even if the code has been pinned in the review window.
- View: Users in the group can view and search for the category or code, but they cannot apply or remove the code from documents.
- Apply: Users in the group can view, search for, apply, and remove the category or code from documents..
- Create (category and coding sheet only): Users in the group can create new codes in the category while performing review
Project Admin or Codes Admin permission is required to edit and delete categories and codes.
The coding sheet is arranged hierarchically, with the entire coding sheet (“All Codes”) at the top, followed by the individual categories, and ending with the codes within the categories. You can use the arrow
buttons to expand or collapse different levels of the coding sheet.
Permissions set at one level cascade down to all levels below in the hierarchy. This helps ensure a user group has uniform permissions, either over the coding sheet as a whole or within particular categories. For example:
-
Create permission at the coding sheet level sets all category permissions to Create and all code permissions to Apply
-
View sets all the individual code permissions to View as well.
- If permission changes result in non-uniform permissions at a given level, the permission for the higher level(s) display as Custom. For example, if you’ve given Apply and View permissions to different codes within a category, the category and coding sheet permissions will both display as Custom
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 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 reflects 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 automatically receives View permissions on the new code, because that is the highest existing permission on a code in that category.
- 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.
Freeform code permissions
Permissions on freeform codes are similar to permissions on categories and codes, except that freeform codes have Edit permissions instead of Apply permissions.
Only Project Admins and Codes Admins can create new freeform codes, edit the names of freeform codes, or delete them from the project entirely.- None: Users in the group have no access to the code. They cannot view, search for, or apply the code to any documents, even if the code has been pinned in the review window.
- View: Users in the group can view and search for the code on documents, but they cannot apply, remove, or edit the value of codes.
- Edit: Users in the group can view, search for, apply, edit and remove the code from documents.
To learn more about applying freeform codes, please visit our article How to Code a Document in the Review Window and Use Coding Presets.
Metadata permissions
Metadata has a single permissions level: Edit. When Edit is selected, users in the group can edit select metadata fields that have been made editable by project admins.
In the Metadata tab of Project Settings, Project Admins can select which metadata fields are editable. Users in a group that do not have Edit permission on Metadata can not edit any metadata field, even those designated as editable by project admins. Metadata fields that are not explicitly made editable by Project Admins are not editable by any user on the project. Read our Metadata Tab of the Document Review Window article or more information about editable metadata.
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 be able to view ratings. Therefore, granting certain permissions also automatically grants other permissions.
The table below lists the permissions that grant additional permissions. If a user group already has permissions that are higher than the minimum additional permissions, its permissions in that category are not changed.
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
Deep Dive Full document access If you have any questions, please feel free to contact us at support@everlaw.com.
Everlaw AI permissions
Everlaw AI permissions are granted separately for individual tasks and for batch actions.
Users in groups with Generate permissions for any one of the following:
- Summaries, topics, extractions, document Q&A
- Coding suggestions
- Writing Assistant and Deposition analysis
can generate for that task using Everlaw AI Assistant while reviewing an individual document, or while in a Draft/Deposition in Storybuilder. These individual actions do not use any credits.
The generations that they create are visible to any other user who has View or Generate permission for that task. The exception is document Q&A. These questions/answers are private to the user who asked them, regardless of the permissions of others.
Users in groups that additionally have the Batch actions permission enabled can do batch generations from the results table for any of the tasks for which their user group also has Generate permission. Generations created in a batch use credits, and users confirm the credit amount before they generate. To learn more about credits, see our Manage and Track Everlaw AI Credit and Feature Use article.
The table below is an example of how different permission combinations function for Coding suggestions:
Coding suggestions Permission Batch actions Permission Generate Generate No Can generate Coding suggestions in the review window only Generate Yes Can generate Coding suggestions in the review window and in the results table View Yes Cannot generate Coding suggestions, but can view those generated by others None None/Yes Cannot generate Coding suggestions or see those generated by others Coding suggestion permissions
There are available permission types for coding suggestions:
Permission type
Description
None No access to generated content View View and use existing generated content Generate Generate new content and delete, view, and use existing generated content
Cannot configure prompts
Configure Configure coding suggestion prompts from Project Management > Project Settings
Also includes all Generate permissions
Deep Dive permissions
Deep Dive enrollment is controlled at the Organization level. When a project is enrolled in Deep Dive, the Everlaw AI permission section has a Deep Dive setting. The permissions for Deep Dive include:
- None: No access to Deep Dive
- Ask: Ask, view and delete your own questions
- View and ask: Ask and delete your questions, and view all questions
Project Admins have View and ask permission by default, and all other groups default to None permission.
Individual user permissions
You can view the project and object permissions of any user on your project. Navigate to the Users tab on the Project Settings page. Then, select the button in the Perms. column of the user.
The Project permisisons tab shows you a list of the user's project permissions. If you are also a database admin, the user's database permissions are listed here, as well.
The Object permissions tab shows you a list of the different objects that a user has access to. Within this dialog you can manage permission levels or revoke a user’s access to various objects.
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 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, Everlaw will never automatically expand a group’s current permissions to accommodate a new permission requirement.
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. Codes Admin Administrative access to codes; Create, edit, and delete categories, codes, freeform codes, conditional rules, autocode rules, and code as previous settings; Highest permissions on the coding sheet. Document Access Management Search, and interact with a limited set of documents on the project. 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 Story objects (e.g., Drafts, Timelines);
Receive: Receive all shared Story objects from other users;
Create: Receive all Story objects and create Drafts and Depositions (Stories must be created by project admins);
Admin: Admin access to all Drafts and Depositions, and “Share” permissions on all Stories 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. Create production report exports. Reselect emails of previous production recipients.
Analytics View and manage project analytics Prediction Models None: No access to any prediction models;
Receive: Receive prediction models shared by other users;
Create: Receive and create prediction models, but only edit prediction models you have created;
Admin: Full permissions on all prediction models in the project.
Clustering (Beta) - will only be available on databases where Clustering is accessed None: No access to Clustering
View: View and interact with Clustering (and Clustering neighbors in the review window)
Admin: Full permissions on Clustering, including reclustering
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 Permanent Rotation Rotate PDFs and images permanently in the review window 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.
Create: Add new codes to the category during review.
Freeform codes None: No access to the code
View: View and search for the code on documents;
Edit: Apply, edit, and remove the code.
Metadata None: Cannot edit any document metadata fields;
Edit: Edit values for select metadata fields.
Configure object permissions
You can manage the permissions for objects that have been shared with a group.
To do so:
- Navigate to the Groups tap of the Project Settings page.
- Select the three-dot
- Select Object permissions. This opens a dialog showing the shared objects and the permission level they were shared with.
- You can adjust the permission level for each object, or revoke permissions entirely for any object. You can learn more in our article on object permissions.
- When you're done, select Done.