Table of Contents
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. When you have a matter on Everlaw, the two main permission types you’ll encounter are database permissions and project permissions. This article provides a high-level overview of these permission families and how they relate to each other.
Databases and projects on Everlaw
To understand the distinct, but complementary, scope of database and project permissions, we must first review the difference between databases and projects on Everlaw.
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 and partial. Complete projects contain all of the documents in the underlying database while partial projects contain only a subset of the documents in the database. Each database comes with a default complete project and 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. The table below describes each in more detail.
|
Upload |
Users with this permission can upload new documents into the database and reprocess uploaded documents |
|
Delete |
Users with this permission can delete existing documents from the database |
|
Legal Holds |
Users with this permission can access Everlaw’s Legal Holds tool |
|
Admin |
Users with this permission are granted Upload, Delete, and Legal Holds permissions and have the additional ability to (1) create new projects, (2) assign database permissions to other users, and (3) suspend, reactivate, and delete individual projects (give project or org admin permissions) or the database as a whole. Finally, only database admins have access to the database settings dashboard. |
Please read this help article for more information about database administration.
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.
For more information about project permissions and settings, please see our help article on configuring 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.
For example, you may 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. Such an individual can be granted only upload database permissions.
You may also 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. These individuals can be granted upload and delete database permissions, but only restrictive project permissions.
0 Comments