The ability to control access to documents and tools is crucial to ensuring a secure review environment. Everlaw’s permission types allow admins to precisely grant users access to only the tools they need to do their jobs.
The two main permission types you’ll encounter in Everlaw are database permissions and project permissions.
This article provides a high-level overview of these permission families and how they relate to each other.
Table of Contents
Databases vs. projects
To understand the distinct, but complementary, scope of database and project permissions, we must first review the difference between databases and projects.
Each matter in Everlaw is associated with a single database. When documents are uploaded into the matter, “clean” versions of them are stored in the database. Each database, in turn, can be associated with an unlimited number of projects.
Projects are the user-facing review environment where users can further organize, annotate, and code documents. Each project is self-contained, and has its own permissions, review codes, and review work product. Thus, a given document can appear in multiple projects and have different review product applied in each project.
There are two types of projects in Everlaw:
- Complete projects contain all of the documents in the underlying database
- Partial projects contain only a subset of the documents in the database
Each database comes with a default complete project. Database admins can optionally add other projects.
When new documents are uploaded into a matter, they are automatically sent to any and all complete projects associated with the database and to any partial projects that are selected by the user.
Documents can be removed from projects without removing them from the underlying database. But documents deleted from the database will be removed from all of the projects that contained those documents.
Because databases and projects are distinct, they also have independent sets of permissions associated with them. In brief, database permissions give users control over documents in the database and the number of associated projects. Project permissions give users control over features and tools within a specific project. Users in your matter can have any combination of database and project permissions, depending on the scope of their responsibilities.
Database permissions
There are four types of permissions that fall under database permissions: Upload, Delete, Legal Holds, and Database Admin.
|
Upload |
Users can:
|
|
Delete |
Users can delete existing documents from the database |
|
Legal Holds |
Users can access Everlaw’s Legal Holds tool |
|
Admin |
Users are granted Upload, Delete, and Legal Holds permissions. They can also:
Only Database Admins have access to the database settings dashboard |
To learn more about database administration, visit Database Administration and Permissions.
Project permissions
Project permissions grant access to features and tools within individual projects. These tools include codes, assignment groups, binders, project-level user group permissions, project-level document access restrictions, and predictive coding models. Because projects are self-contained, permissions granted and actions taken in one project will not be reflected in another project, unless a user with proper permissions affirmatively chooses to copy settings and work product between projects.
To learn more about project permissions and settings, visit User Groups and Project Permissions.
Example scenarios
Database and project permissions do not interact with each other, so you can have users with highly differentiated permissions depending on their scope of responsibilities.
Example #1: You have someone in your office who is responsible for loading new data into the platform, but cannot otherwise know anything else about a review project.
In this case, you can limit them upload database permissions only.
Example #2: You have colleagues who you want to freely upload and delete data, but who should not be modifying any of the review parameters you set up in the primary project.
In this case, you can grant them upload and delete database permissions, while limiting them to restrictive project permissions.