ShareDo Document Management Integration

How does ShareDo integrate with a DMS?

ShareDo integrates with Document Management Systems (DMS) using a provider pattern. The major DMS that we integrate with are:

O365 - SharePoint Online
iManage (on-premise and cloud)
NetDocuments

We have also used the provider model to build bespoke document management integrations to:

Amazon S3
SMB Network file shares
and APIs exposed on Azure API Managed Gateway

Additional providers can be built where these are required.

We can do this because we define a document management provider as one that can implement a common set of operations.

These are examples of operations that you would expect for a document management interface.

List files and folders
Create folder
Rename folder
Delete folder
Create file
Rename file
Delete file
Get file metadata
Restore file version
Move files
Copy files

Each provider implements these operations differently, but to the ShareDo user interface, the API calls it makes to the ShareDO API are the same. For example:

Authentication and Authorisation

Most of the DMS integrations we support use an OAuth flow for authentication. The typical flow we support for this is Authorisation Code with PKCE. This flow makes a request for a user-based token from the DMS API. The DMS handles the authentication and MFA for this request and requires user interaction. ShareDo will encrypt and store the Access and Refresh tokens on a per-user basis.

This approach means that users typically interact with the DMS using their own identity and have the permissions their user account would have if they were directly communicating with the DMS.

ShareDo Document Repositories

ShareDo describes its configuration to a specific location in the DMS as a document repository. This section describes what a document repository is, what repositories we need, and how they are configured.

What are document repositories?

A document repository is a pointer to a specific location in a specific DMS. A document repository may or may not be associated with an instance of a ShareDo work item and may use properties from that work item to establish the location.

Examples:

Document repository location not associated with a work item.
We often describe a document repository location for document templates. This is used to store the document templates that are used in document generation. This is often a static location in a document library (O365), workspace (iManage) or cabinet (NetDocuments). No work item context is used to resolve this location, and all users see the same view.

Document repository location associated with a work item.
We will usually have several document repositories defined and associated with work items.
We often use properties of the work item to determine the location for these documents. These properties can be any field available in the Data Composer for the work item.
For example:

O365 - Matter Documents

Worktype: matter 
Site: /sites/Sharedo 
Document Library: Matters 
Folder: [workitem.reference]

This example would store all the documents for a matter work type in an O365 site called Sharedo, in a document library called Matters. It would create a new folder for each matter based on the reference associated with the matter work item.

iManage - Matter Documents

Worktype: matter 
Database: ACTIVE 
Workspace: custom1=[workitem.roles.client.ods.reference], custom2=[workitem.reference] 
Folder: Documents

This example would store all the documents for a matter work type in the ACTIVE database in iManage. In a workspace that would have custom1 set to the reference of the client participant of the matter and custom2 set to the reference of the matter. Documents would be stored in the Documents folder, which is the view seen in ShareDo.

There are more in-depth examples of the configuration options for specific providers on the following pages:

Determining Document Repositories by Type Inheritance or Relationships

An important concept with document repositories is that they can be associated with work items and that a document repository can be determined through ShareDo type inheritance and ShareDo relationships.

Document Repositories and ShareDo Type Inheritance
Matter Documents is a default repository that is defined in ShareDo.
By default, this document repository is associated with the work item type Matter.
This means that any work type created as a derived type of Matter, and does not have its own document repository assigned, will use this ter Documents repository location.
Document Repositories and ShareDo Relationships
There are often work items for which we don't want to define a document repository location; instead, we want them to get this location based on their context.
For example, a document generation task that produces a document should store the created document against its parent's work item. Configured without a repository, ShareDo will determine the closest parent work item that has a repository defined.
This means that the document generation task can be created as a child of an instruction, matter, proceeding, etc., and it will use the repository of its nearest parent that has a repository defined.

What document repositories do we need?

ShareDo environments usually ship with some pre-configured repositories. If the information about your target repository locations is known up front, then this can be scripted into the environment build. If you need time to decide, we can ship with placeholders for your intended DMS.

The following document repositories are typically added as a set of defaults. They aren't all necessarily needed. It depends on your use case.

The table below lists the defaults that are usually added and their purpose.

Administration (non-work item-related) repositories

Templates	Location for document templates that are to be used in document generation.
Data Table Uploads	Location used to temporarily store Excel and CSV files associated with a dataload activity.
Scanning	Location used to store inbound scanned post items that need to be filed to work items.
Printing	Location used to store document generation items fulfilled by Post.

Work item repositories

Instructions	Location for documents associated with an instruction.
Inbound Emails	Location used to temporarily store attachments associated with inbound emails before they are filed to an appropriate work item.
Matters	Location for documents associated with matter documents.
Email Archive	Location used to store copies of inbound and outbound emails once they are sent (although for outbound, only where not a child of a work item with a repository).
Client Documents	Location used to store documents for a specific client.
Service Requests	Location to store documents associated with a service request work item.

As a system configurator, it is important to consider where you will store documents that fall into these categories in your DMS. Then to look at the scalability of that DMS, to ensure the volumes of documents you want to put into that location will work for the DMS.

Adding More Document Repositories

Organisations can configure additional document repository locations. This could be a static location to store specific files or a work item based location - e.g. creating a document repository location for Statement of Work items, so these can store contractual documentation.

A common requirement could be that we want to have completely different document locations for different practice areas. These could even be completely different document management systems.

This is where the inheritance and relationship model is useful.

Example:

O365 - Matter Documents - Real Estate

Work Type: matter-real-estate
Site: /sites/Sharedo-RealEstate
Document Library: Matters
Folder: [workitem.reference]

O365 - Matter Documents - Defendant Disputes

Work Type: matter-defendant-disputes
Site: /sites/Sharedo-Disputes
Document Library: Matters
Folder: [workitem.reference]

The above would mean that any matter type derived from matter-real-estate would use the Matter Documents - Real Estate document repository, whereas matter types derived from matter-defendant-disputes would use the Matter Documents - Defendant Disputes document repository.

Based on the contents of this article, you might also see a different way to solve this without adding a new repository:

O365 - Matter Documents

SystemName; matter-documents
Work Type: matter
Site: /sites/Sharedo-[workitem.practiceArea]
Document Library: Matters
Folder: [workitem.reference]

Here - we've kept the repository inheritance the same, but we can use Data Composer to build out the O365 site name based on a form field on the work item called PracticeArea. This would need to be populated, or it may be something that could be derived as a calculated field.

How do you add new document repository settings?

Unfortunately, this is still a manual and cumbersome admin effort, which can be completed in the Admin > System Settings area. This is only typically done a few times in each environment. Often, the scripted defaults are sufficient. Where we need to add new settings, several keys specific to each DMS need to be applied.

Find the configuration for these repositories by doing the following:

Open Launchpad > Admin > System Config > System Settings.
Scroll down to Repository and click the button.
Use a filter on the Key column to find repository.matter.
Edit as necessary.

You can also create new keys by using the Add button on the top-right of the Repository Settings blade.