Table of Contents
- What is a database
- Types of database permissions
- Database settings page
- Adding and administering projects
- Administering database permissions
- Suspending, deleting, exporting, and reactivating
- Overlapping Bates
- Database admin activity audit log
- Upload notifications
What is a Database?
On Everlaw, your database is the central storage location for all documents in your matter. When you upload documents to Everlaw, they go into your database. Documents in your database are then made available for review in projects. Projects are self-contained, user-facing review environments where users can organize, tag, and annotate documents, among other things.
Actions taken at the database-level affect all projects in the database, while actions taken within a project are generally localized to that project. For this reason, the type and scope of permissions for database administrators differ from those of project administrators, and each family of permissions can be treated independently. For a high-level overview of the difference between database and project admins, please see this help article.
Types of Database permissions
There are four types of database permissions:
- Upload: View, create, edit, and manage native uploads; submit documents to be uploaded as processed data; and reprocess documents. Note that users must also have the Partial Project Document Management permission to upload documents to partial projects.
- Delete: Delete documents from the database and delete native uploads from the Uploads Page. Note that Upload permission is required to access the Uploads Page.
- Legal holds: Create, administer, and access legal holds for the database.
- Database Admin: Includes Upload, Delete, and Legal Holds permissions, plus: create new partial projects; rename, export, suspend, reactivate, and delete individual projects (requires Project Admin permissions on the project); suspend, reactivate, or delete the entire database; grant and revoke database permissions for other users; configure upload notifications; and view all users in the database.
Each permission can be granted independently of the others, with the exception of the Admin permission which includes all the other permissions.
Database settings page
Users with database admin permission have access to the Database Settings page. This page is accessed from the Project Management menu in the navigation bar, and contains functionality for administering projects and users in a database, as well as the database itself.
The table below briefly summarizes the functionality found on the four sub-pages of Database Settings.
Adding and administering projects
Interaction between database and project-level permissions
If you are a database admin, you can see all projects in the database on the projects table.
But, while all projects are visible, the ability to perform project-level actions is dependent on your organization and project-level permissions:
- If you are an organization admin, all project-level actions will be available (rename, export, suspend, delete, convert partial projects to complete, and access the project home and setting pages).
- If you are a database admin, but not an organization admin, and:
- You are a project admin of a project, all project-level actions are available, except for converting the project from partial to complete.
- You are only a member of a project, the only project-level action that is available is accessing the project’s homepage.
- You are not a member of a project, no project-level actions are available.
In the example above, the user is a project admin of the default project, a member of the Highland Cow project, and not a member of the Sheep, Goat, and Cat projects.
Adding new projects
Database admins can add an unlimited number of new projects to their database. To add a new project, navigate to the Overview page of Database Settings and click the “Add new project” button above the project table. You will be prompted to give your new project a name and you can optionally copy configuration settings over from an existing project.
New projects are, by default, partial projects and contain no documents. You will automatically be added as a project admin on any project you create from Database Settings.
To learn more about projects, see this article.
Projects that you have proper permissions over can be renamed by clicking the pencil icon next to a project’s name in the table. The existing name will be highlighted and you can type in the new name.
The projects on the table are sorted by alphanumeric order. Note, however, that the default complete project in a database cannot be renamed and will always appear as the first project on the table.
Converting partial projects to complete
If you are an organization admin for the organization that owns a database, you can convert projects from partial to complete. Click on the “Actions” menu corresponding to the project you want to convert and select the convert option from the dropdown.
The primary difference between partial and complete projects is that complete projects are always automatically in sync with database documents, whereas documents must be affirmatively added to a partial project.
For more information about projects, see this article.
Administering database permissions
As a database admin, you can administer database permissions for other users, including other database admins. To administer permissions, navigate to the Permissions page of Database Settings.
The top table displays all active users in the database who have some form of database permissions. An “active” user is a user who is a member of at least one project in the database.
To modify the permissions of an existing user, click on the permissions column corresponding to the user, and select or deselect to modify.
To remove a user’s database permissions entirely, click on the “X” in the remove column corresponding to the user. The user will have their database permissions revoked, but this will not affect their project permissions or access.
To give new users database permissions, click on “Add user” at the bottom of the table. A dropdown list will appear displaying all users who are currently members of a project in the database, and thereby eligible to receive database permissions. You can search to filter this list. Remember that a user must be a member of at least one project in the database for them to appear on this list.
If you are (1) on a suspended database and (2) are a project admin of the default project, you will have the additional option to give database permissions to users who are not already members of a project. Any users added through this method will also automatically be added to the default project.
Inactive database users
When a database user is removed from all projects in a database, they become an inactive user. This means that they previously had database permissions, but they no longer have access to any projects in the database.
Inactive users are not able to perform any actions on the database or its projects, but if they are re-added to a project in the database, they will automatically receive their database permissions again. To remove all database permissions from an inactive user, click “Remove” to the right of their name in the "Inactive users" list. If they are then re-added to a project in the database, they will not have any database permissions until the permissions are explicitly granted again.
Note: Organization admins who have database admin permissions will maintain their database admin permissions, even if they become "inactive users." Learn more about OA access.
If the sole database or organization admin is removed, please know that you will be unable to suspend or delete your database without reaching out to Everlaw support.
Suspending, deleting, exporting, and reactivating
Database admins can freely suspend, delete, and reactivate individual projects (depending on permissions) or the database as a whole. These options are available on the Overview page of Database Settings.
To suspend, reactivate, or delete a project, click the action menu corresponding to the target project and select a desired action.
If a project is already suspended, it will be marked as such on the table and the reactivate option will appear in the action dropdown.
Suspending and deleting databases
To suspend or delete a database, select the desired option in the database summary section at the top of the Overview page.
Note that database-level actions affect all projects in the database, even those that you are not a member or admin of. If you are suspending or deleting a database with such projects, a warning will appear alerting you to this fact and confirming that you wish to continue.
Once confirmed, follow the instructions in the remaining steps to confirm the suspension or deletion.
Suspending a database will make the projects in the database temporarily inaccessible to all users, but all work product and review configurations will be preserved. Database admins can, however, still navigate to Database Settings and perform administrative actions, including exporting documents and review product from projects.
To navigate to Database Settings for a suspended database, click on one of the database projects in the suspended section of the project selector. Note that the suspended section only appears for database admins.
Deleting a database will make both the projects and the database permanently and immediately inaccessible to all users, including database admins. If you want Everlaw to purge any and all backups of the database as part of the deletion, be sure to select that option on the final deletion dialog.
Note that purging all backups will make it impossible for Everlaw to recover any of your work product and documents should you need it later. Please choose this option only when necessary, such as when ordered by a court.
To reactivate a suspended database, click the reactivate button on the Overview page.
On the reactivation dialog, you can choose which projects you want to reactivate as part of reactivating the database. Note that at least one complete project must be reactivated for the database to be reactivated.
You can also reactivate a suspended database by attempting to reactivate a project in the database. Everlaw will detect that the underlying database is suspended, and will reroute you to the database reactivation option.
You can export project data even while the database or project is suspended. Note that you must be either (1) a database admin and a project admin on the project you are attempting to export, or (2) an organization admin on the database, to export projects from the overview page of database settings. Because you cannot modify project permission settings after a database is suspended, we highly recommend that you ensure you have the proper project permissions to perform desired exports before suspending the database.
To start an export, click the three dot menu icon associated with the project you wish to export, and select "export project."
A dialog will appear where you can select project data and files you want to include in your export, along with other settings.
Keep in mind, however, that certain project data is not exportable via the project export, and can only be exported from specific areas of the platform while the project is active. Data in this category include: search term reports (STRs), Storybuilder Timelines, Storybuilder Drafts, Storybuilder Depositions, and platform messages.
Billing implications of suspensions and reactivations
Below are some important things to keep in mind as you assess the billing implications of suspensions and reactivations. As always, please check your contract or reach out to our Customer Experience team (firstname.lastname@example.org) to understand or verify the implications of a suspension.
- Billing generally occurs at the database level, so individual project suspensions and deletions will generally have no effect on the billable size of your matter. The exception is if you delete the last remaining review project in an ECA database, as this removes any promoted data.
- Databases are billed at the suspended rate only if the database is suspended for a full calendar month. In other words, if the database becomes active at any point in the month, the database will be billed at the active rate for the entire month. This also means that suspending a project earlier in the month versus later in the month has no billing implication.
- Everlaw runs on UTC time, which means new billing cycles start on the first of each month UTC time. This is especially important to keep in mind if you are suspending or reactivating databases on the first or last day of the month.
- For example, May 1, 2022 at 12am (UTC) corresponds to April 30, 2022 at 5pm (PDT). If you are in the PDT time zone and suspend your database at 5:03pm on April 30th, you will still be billed at the active rate for the month of May because the database was active in May (UTC time).
- Similarly, May 1, 2022 at 12am (UTC) corresponds to May 1, 2022 at 10am (AEST). If you are in the AEST time zone and reactivate your database at 9am on May 1st, you will be billed at the active rate for the month of April because the database was active in the April (UTC time).
By default, Everlaw does not allow for documents with overlapping Bates ranges. For example, if ABC001 is a two-paged document, Everlaw normally wouldn't allow for the upload of ABC002 because ABC002 is already occupied by the second page of ABC001.
However, database admins can allow overlapping Bates to occur by toggling the option in the General page of Database Settings.
While turning this option on will allow documents to have overlaps in their Bates ranges, it will not allow documents to have overlapping Begin Bates. Everlaw requires processed data to have a unique identifier representing the beginning of a document (such as Begin Bates number or Control Number). For example, the following three documents would be considered to have overlapping Begin Bates numbers and would not be uploaded to the platform:
The following scenario would be enabled by allowing for overlapping Bates:
Let’s say you are uploading ABC001 (3 pages), ABC002 (2 pages), and ABC003 (1 page). ABC002 and ABC003 have Bates ranges that overlap with ABC001.
These documents will be successfully uploaded because their Begin Bates do not overlap even though there is overlap in their Bates ranges.
This setting is especially relevant for users in countries, such as Australia, with document numbering systems that do not rely on End Bates numbers.
If the setting is toggled off after being on, only future uploads will be affected. Existing documents with overlapping Bates ranges will remain unmodified in your database.
Note that allowing overlapping Bates can sometimes create uncertainty for processed uploads when overlaying with separate files for each image. This can happen if two documents have overlapping Bates ranges and there are single-page images within the overlapping area. For example, if ABC001 and ABC002 are both five-page documents, ABC003.tiff may be assigned to either of these documents.
Note for AU, UK, and EU users: By default, the “Overlapping Bates” setting will be enabled for all new databases.
Learn more about standard formats for processed data.
Database admin activity audit log
The Admin activity page of Database Settings contains a log of all database admin events. This log can be filtered by datetime, user, or event type.
Database administrators can also configure upload notifications for any projects that they are added to in the database. To learn more about upload notifications, please see this help article.