On January 11, 2019 (EU, CA, AU: January 18, 2019), we will release an update to permission settings on Everlaw. With this release, certain features and tools that did not previously have configurable permissions will receive their own permissions. This will make it easier to only give users access to the tools they need.

Please note: This update will not require admins to make any changes to existing permission settings. Though we are introducing new permissions to the platform, all non-admin users will retain their current level of access to platform features. We will automatically transition all current permissions to the new paradigm during the update.

 

This article describes new permissions to be introduced with this update, modifications to existing permissions, and the transition from Everlaw’s current permissions paradigm to the new paradigm.

Table of Contents

• Permissions list
• Project permissions
  • New project permissions
  • Modified project permissions
• Database permissions
• Organization admin permissions
• Transitioning permissions
• Permission dependencies
• Determining permissions for future features

 

Return to table of contents

Permissions list

The following is a complete list of configurable permissions on Everlaw, effective January 11, 2019:

Project Permissions

Project permissions grant user groups access to features and tools within individual projects. Generally, actions made permissible by project permissions do not affect other projects in the database.

• Project Admin [Previously Case Admin]
• Partial Project Document Management [New]
• Search Term Reports [New]
• CSV Export [New]
• PDF Export [New]
• ZIP Export [New functionality]
• Document Download
• Storybuilder [New]
• Productions [New]
• Analytics [New]
• Prediction Models [New]
• Document History [New]
• Batch Updates
• Context Panel Updates
• Unitization [New]
• Assignment Groups [New]
• Redactions [New options]
• Notes and Highlights
• Ratings
• Categories and Codes
• User Fields [Each field will have its own permission setting]
• View Case [REMOVED]

Database Permissions [New]

Database permissions grant individual users the ability to perform actions that affect all projects in a database.

• Upload
• Delete [New]
• Database Admin [New]

Organization Admin Permissions [New]

Organization admin permissions grant organization admins permissions on the organization’s database and projects.

• Organization Admin Access [New]

Return to table of contents

Project permissions

Project permissions grant user groups access to different features and tools within individual projects on Everlaw (e.g., search term reports, assignment groups, redactions). Generally, actions made permissible by project permissions do not affect other projects in the database.

Return to table of contents

New project permissions

Groups with the Project Admin (previously called Case Admin) permission will have full project permissions. Groups must have Project Admin permissions in order to create and administer users and groups, categories and codes, user fields, metadata, and perform all other actions  under the Project Settings (formerly “Case Settings”) page. Additionally, only project admins will be able to view user activity and email threading on the Analytics page.

All groups with the “Case Admin” permission on January 11th will become project admins with this update. Transitioning current permissions to the new permissions paradigm will be discussed in greater detail in the “Transitioning permissions” section.

The Partial Project Document Management permission, which will only exist on partial projects, controls the ability to add documents to, or remove documents from, the partial project. Please note that the ability to add documents to partial projects upon upload will now require this permission. It will no longer be the case that all uploaders can add documents to any partial projects simply by virtue of having upload permissions. Users will need to have the Partial Project Document Management permission on each partial project in order to add documents to it. All groups with the “Case Admin” permission on January 11th will receive this permission on each project they are a member of.

The ZIP Export permission will control a user’s ability to export a zip file containing the image, text, native, and load files for a document set, as well as the documents’ review work product.

All groups that have the “Download Documents” permission on January 11th will receive the ZIP Export permission with this update.  

Search term reports, assignment groups, prediction models, Storybuilder, and productions will all receive individual permissions with this update.

Permission options for search term reports, assignment groups, and prediction models:

• None: No access. Other users will not be able to share such objects with those who have “None” permissions. (Please note that the Assignment Groups permission controls access to assignment groups; all users will remain able to receive individual assignments.)

• Receive: Receive shared objects from other users, but cannot create any new ones. Users in groups with “Receive” permissions can still be given any level of permissions (e.g., “View,” “Edit,” “Share and Delete”) on individually shared objects.

• Create: Receive and create objects. Users in groups with “Create” permissions can still be given any level of permissions (e.g., “View,” “Edit,” “Share and Delete”) on individually shared objects.

• Admin: Full access on all objects in the project.

Storybuilder will have the same permission options, but they will have differential applications for different Storybuilder tools:

• None: No access to any Storybuilder objects (e.g., Drafts, Timelines, Depositions). Other users will not be able to share such objects with those who have “None” permissions.

• Receive: Receive all shared Storybuilder objects from other users, but cannot create any new ones. Users in groups with “Receive” permissions can still be given any level of permissions (e.g., “View,” “Edit,” “Share”) on individually shared objects.

• Create: Receive all Storybuilder objects, and can create Drafts and Depositions. Stories must be created by project admins. Users in groups with “Create” permissions can still be given any level of permissions (e.g., “View,” “Edit,” “Share”) on individually shared objects. 

• Admin: Full permissions on all Drafts, and “Share” permissions on all Stories in the project.

Please note that currently, users can create Drafts associated with any Stories they have access to. However, with the January 11th update, users will need to have the “Create” permission on Storybuilder in order to create Drafts, regardless of their access to individual Stories.

If a group is given the “None” permission on search term reports, assignment groups, prediction models, or Storybuilder, all of their access to the tool will be revoked, including their access to objects they have created. For example, if someone with “Create” permissions on search term reports has their permissions downgraded to “None,” they will lose all access to search term reports, including any search term reports they have created. Only objects (e.g., search term reports, assignment groups) that have been shared with “All users” will be automatically shared with users who later have their permissions restored. Otherwise, objects will have to be explicitly re-shared with users if their permissions are later restored.

All non-admin groups will be granted “Receive” permissions on search term reports, assignment groups, prediction models, and Storybuilder with this update on January 11th. Admin groups will be granted “Admin” permissions on these tools with this update. 

Productions will have three permission options:

• None: No access to the Productions page. All users will remain able to search for and view documents that have been produced.
• Share: Download and share all productions.
• Admin: Create, modify, download, and share all productions.

All groups with the “Case Admin” permission on January 11th will receive the “Admin” permission on productions with this update. Transitioning current permissions to the new permissions paradigm will be discussed in greater detail in the “Transitioning permissions” section.

Return to table of contents

Modified project permissions

In order to make the administration and interpretation of permission settings easier and more transparent, we have updated and simplified a number of permission settings options.

Project Admin

With this update, all groups with the “Project Admin” permission (currently the “Case Admin” permission) will have full administrative access to all project settings, including all categories and codes on the project. It will no longer be possible to restrict admin access to certain categories and codes, ensuring a consistent view and experience for all project admins.

Ratings

The current permission options for ratings are “None,” “View,” and “Edit.” With this update, the “Edit” permission will be renamed to “Apply” for clarity. This will not change the level of access associated with each permission setting.

Codes

The current permission options for codes are “None,” “Read,” “Create,” and “Admin.” With this update, the permission options for codes will change to “None,” “View,” and “Apply.” All non-admins will retain their current level of access to codes. All project admins, and only project admins, will have administrative privileges over all codes.

Additionally, to provide greater clarity into users’ permissions, coding permissions will be assignable only to groups, rather than to individual users, “All users,” or, “All administrators.” If any individuals on your project were given user-specific permissions on categories or codes prior to this permissions update, Everlaw will add them to their own groups with the proper permissions on codes.

Finally, to streamline the process of assigning coding permissions, we have moved the administration of all coding permissions from the Categories & Codes tab to the Permissions tab. You will now be able to assign permissions on all codes from the same place, at the same time.

Document redactions

The current options for document redaction permissions are “Yes” and “No” (via checkbox). These two options will expand to four options with this update:

• None: No access to redactions applied prior to production. (All users will remain able to view redactions that have been burnt in during production.)

• View: View all redactions and redaction notes.

• Create: View and apply redactions and redaction notes, but only modify those which they created.

• Admin: Full permissions on all redactions and redaction notes. 

Notes and highlights

The current permission options for notes and highlights (currently titled “Notes”) are “None,” “View,” and “Create.”

These three options will expand to four options: “None,” “View,” “Create,” and “Admin.” The “Admin” permission will give users full permissions on all notes and highlights, including the ability to delete notes and highlights that others have applied.

This will be described below in the “Transitioning permissions” section, but users who currently have the “View” permission on notes will receive the “View” permission on Notes and Highlights, as well as the “View” permission on redactions with this update. This is because the current “View” permission on notes allows users to view all notes, highlights, and redactions.

Additionally, users who currently have the “Create” permission on notes will receive the “Admin” permission on Notes and Highlights, as well as the “View” permission on redactions with this update. This is because the current “Create” permission on notes allows users to edit and delete notes that others have applied, as well as view all notes, highlights, and redactions.

A note on redaction notes: The new Notes and Highlights permissions will control access to notes created on batch redactions. The new Notes and Highlights permission will not affect notes on individual redactions. Note permissions on individual redactions will be governed by the Redactions permission.

View Case

In an effort to increase visibility into who has access to specific projects on Everlaw, the “View Case” permission will no longer exist. All users who exist on a project after January 11th, 2019 will be able to view the project.

Return to table of contents

Database permissions

Database permissions (Upload, Delete, and Database Admin) will grant users the ability to upload and delete documents in the database, as well as create new projects. While the ramifications of project permissions are generally limited to the project in which they were granted, users with database permissions can affect multiple projects in a database, including projects which they have not been explicitly added to. Uploading documents to any project in a database affects all complete projects (i.e., projects containing all database documents) in the database; deleting documents from any project in a database deletes them from all projects--partial and complete--in the database. Database permissions are granted to individual users, rather than user groups, and can be granted to anyone on a database.

Only users with the Database Admin permission will be able to grant upload, delete, and database admin permissions to other users, as well as create new projects. In order to grant database permissions to other users, database admins will have access to a complete list of all users on a database.

Only users in groups with the Upload permission on January 11th will receive database permissions with this update. Transitioning current permissions to the new permissions paradigm will be discussed in greater detail in the “Transitioning permissions” section.

Return to table of contents

Organization admin permissions

Currently, all organization admins have a special level of access to all databases and projects belonging to the organization. This special level of access grants organization admins:

1. Administrative access to databases on the Organization Admin page (e.g., rename databases, manage processed uploads);
2. Administrative access to projects on the Organization Admin page (e.g., suspend/delete projects, view tasks, view user uploads);
3. Organization admin-only access on projects (e.g., assign Bates, administer all project binders, configure deduplication settings).

With this January 11th update, the organization admin privileges listed above will be controlled by the Organization Admin Access (OA Access) permission, located on the Organization Admin page.

By default, the OA Access permission will be set to Yes for all databases. If OA Access is set to Yes for a database, all organization admins will have their current organization admin-level of access to the database, as well as all projects in the database, regardless of whether they have been explicitly added to the projects or not.

However, if the OA Access permission has been set to No for a given database, organization admins will no longer have automatic access to the database and its projects. In order to administer the database and its projects from the Organization Admin page (#1 and #2 above), as well as maintain organization admin-level access to the projects themselves (#3 above), organization admins must be:

1. Added to at least one project in the database (with any project permissions); and
2. Granted the Database Admin permission on the database.

If an organization admin is added to a project but is not granted the Database Admin permission, their project permissions will be derived solely from the user group(s) they have been added to. They will not be able to administer the database or any of its projects from the Organization Admin page.

Please note that all organization admins will be able to see the sizes of all of the organization’s projects from the Organization Admin page, regardless of OA Access settings.

Return to table of contents

Transitioning permissions

On January 11th, users and user groups will automatically receive updated permissions in accordance with their current permission settings. The following table enumerates which current permission settings (i.e., permission settings on January 11, 2019) will dictate permissions in the new paradigm. Please note that project admins (i.e., current case admins) will receive the highest permission option for each project permission with this update. 

Only groups which currently have this permission:	Will automatically receive the following permission(s):
Case Admin	Project Admin (all permissions); Partial Project Document Management; Analytics; Productions: Admin; Unitization
Rating: None	Ratings: None
Rating: View	Ratings: View
Rating: Edit	Ratings: Apply
User Fields: None	All User Fields: None
User Fields: View	All User Fields: View
User Fields: Edit	All User Fields: Edit
Context Panel Update	Context Panel Updates
Batch Update	Batch Updates
Download Documents	Document Download; CSV Export; PDF Export; ZIP Export
Redact Documents: Yes	Redactions: Admin
Redact Documents: No	Redactions: None
Notes: None	Notes and Highlights: None
Notes: View	Notes and Highlights: View; Redactions: View (see “Modified project permissions” section for details)
Notes: Create	Notes and Highlights: Admin; Redactions: View (see “Modified project permissions” for details)
All non-case admin groups*	Search Term Reports: Receive
All non-case admin groups*	Storybuilder: Receive
All non-case admin groups*	Prediction Models: Receive
All non-case admin groups*	Assignment Groups: Receive
Upload (see below for additional requirements)	Database Permissions (see below for details)
Codes	All non-project admins will maintain current access on all codes (see below for details)

*Current case admin groups will automatically be granted “Admin” permissions on all tools, as a function of their new Project Admin permission.

Transitioning database permissions

On January 11th, all users with the “Upload” permission will receive Upload and Delete permissions with the new permissions update.

On January 11th, all users with the “Upload” permission and who have access to all users in the database (i.e., all users in all projects) via their project membership will receive Upload, Delete, and Database Admin permissions with this update. In other words, in order to receive all three database permissions, the user must already have access to all users across all projects in a database. This additional requirement exists because database admins will be able to view a list of all users on the database (i.e., all users on all projects in the database). We will therefore only automatically grant the Database Admin permission to uploaders who already have access to all users in the database by virtue of their membership on the database’s projects. Please note that if a user who was automatically granted the Database Admin permission is later removed from a project and therefore loses access to certain users in the database, they will will retain their database admin status until it is explicitly revoked. Any user can later be made a database admin manually (i.e., after the automatic update on January 11, 2019), regardless of their access to users.

If a database has no uploader, no one will be granted database permissions with this update. Please contact Everlaw support (support@everlaw.com) to grant someone database permissions on your database.

Transitioning coding permissions

Project admins (i.e. users who have the “Case Admin” permission on January 11, 2019) will receive full administrative permissions on all codes in the project. For users who are not project admins, their ability to view and apply codes will not change with this permissions update. Their full set of permissions on categories and codes, however, will now be accessible from the Permissions page. If any non-case admin has been individually granted permissions on a category or code (i.e., their name currently appears on the category or code’s permissions table) and none of their groups have the same permissions, Everlaw will create an additional, separate user group for that individual with the proper coding permissions.

In the new permissions paradigm, only user groups (i.e., not individual users) can be granted permissions on categories and codes. Any non-admin users who have individual permissions on categories or codes prior to this update (e.g., Darby Henry in the above image) will be added to their own group with the proper category and code permissions during this update. This will ensure users with individually-granted permissions retain their proper level of access on categories and codes.

Transitioning prediction model permissions

Currently, non-case admins are unable to view predictive coding models on the Predictive Coding page. In the new permissions paradigm, however, non-project admins will be able to view any model that has been shared with them if they have “Receive” permissions. Because all users will be automatically given “Receive” permissions on Prediction Models with this update, any models that a user has “Read” or “Admin” permissions on (as of January 11, 2019) will become accessible to them on the predictive coding page.

Organization admin access

All projects under organizations will have the Organization Admin Access permission enabled (i.e., set to Yes) by default with this update. This means that all projects under an organization will remain accessible to all organization administrators until their access is revoked (i.e., OA Access set to No).

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. With this permissions update, granting certain permissions to a group will require that other permissions are also granted. The below table lists the permissions which will 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; Ratings: View
Productions: Admin	Notes and Highlights: View; Redactions: View; All Codes: View; Ratings: View; All User Fields: View
Analytics	Ratings: View; All Codes: View

 

 

Return to table of contents

Determining permissions for future features

We are regularly adding new features to Everlaw, some of which may be released with their own permissions. To save project admins time when we release new features, we will 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 all new features. If a new feature permission requires  existing permissions that a group does not already have (e.g., a new analytics feature permission 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