How Custom Metadata in Atlas Works

Digitizing case law documentation is one thing, but can you actually find anything in those millions of bytes of data? Here’s how custom metadata in Atlas saves time and quite possibly the legal professional’s sanity. 
 
Case Law – when previous legal cases constitute a binding precedent where the rationale, judgements, legal principles and interpretations of previous cases are documented so they can be applied to new cases – ensures the same practice and application of the law over time. A famous example from the United States is Roe v Wade, but each political jurisdiction, whether local, regional, or national will have hundreds, if not thousands, of cases lawyers are able to review.  

With remote working or work from home practices growing, filing cabinets are hardly fit for purpose when it comes to SharePoint document management. So how do legal firms create a SharePoint document management system where previous case law can be collated, stored, and easily accessed online?

Uploading digitized case law documentation is one thing, but without a powerful search and easy-to-use filtering configuration, that particular case you so urgently need becomes the proverbial ‘needle in a haystack’. An intuitive, user-friendly experience here could be essential to a lawyer finding the right case law document … and winning their case. 

Custom metadata in Atlas 

By configuring custom metadata within Atlas, it's possible to add new columns to produce additional ways of allocating and grouping documents. In this example the following metadata can be applied to case law documents uploaded into this workspace: 

• Case Subject 
• Court 
• Court Location 
• Judge 
• Year 

Case Subjects could be grouped to provide quick access to whichever subject a lawyer may be looking for. The benefits to the user of tagging document against subjects and utilizing these through filtering is clear. 

With Courts acting the same way: 

However, the smartest innovation here comes from the ‘Judges’ column which is managed metadata; meaning the selection comes from a pre-agreed list stored within the SharePoint Term store.  

This allows for more than one option to be chosen, but importantly, the selected metadata chosen appears in the filters as individual options, rather than showing all judges from a document appearing on one line as free text. 

Multiple choices can be added to one document, while each judge can be searched against individually, to bring back any documents that judge has been tagged against (real judges’ names have not been used in any of the examples provided). 

If the metadata wasn't managed through the SharePoint term store, the Judge filter would look return results as per the example below, with each document applying a free text field under judges and grouping them accordingly. The user experience is poor and the power of the search filtering is inhibited. 

 (NOTE: Names blanked out for privacy). 

So that’s how Case Law documents can be collated, grouped, and searched for quickly and easily. But another primary consideration is how complicated it is to add case law to the workspace. If the process for adding documentation is too complex or time consuming, this would impact both productivity and the overall success of the Case Law workspace. 

Fortunately, the answer is: very easily. With the custom metadata added to a customized Add It Configuration file kept within the Case Law workspace only, all additional unique columns here are integrated as new fields into the Add It experience, creating a streamlined process for the easy completion of information. It might take a few minutes longer to complete the additional fields but this is only a one-time effort, with additional time saved every time a user searches for this document.

In the example below, ‘judges’ is a managed term through the term store, the other fields are open text, with Case Summary being the only field that is not mandatory. 


Custom columns and metadata can be applied if additional term sets over and above the standard Atlas terms are required within a dedicated workspace. Some other examples we have seen have been ‘data governance’ as well as ‘policies & process’ documentation.

Have you used custom metadata in Atlas, either in the legal sector or for something entirely different? Or has this sparked an idea of how you could use it in the future? Let us know in the comments.