eDiscovery Daily Blog

• August 26, 2015

If you’ve used any review tool, you’re familiar with the “tag” field to classify documents.  Whether classifying documents as responsive, non-responsive, privileged, or applicable to any of a number of issues, you’ve probably used a tag field to simply check a document to indicate that the associated characteristic of the document is “true”.  But, if you fall in love with the tag field too much, your database can become unmanageable and you may find yourself playing “hide and seek” to try to find the desired tag.

So, what is a “tag” field?

In databases such as SQL Server (which many review platforms use for managing the data associated with ESI being reviewed), a “tag” field is typically a “bit” field known as a yes/no boolean field (also known as true/false).  As a “bit” field, its valid values are 0 (false) and 1 (true).  In the review platform, the tag field is typically represented by a check box that can simply be clicked to check it as true (or click again to turn it back to false).  Easy, right?

One of the most popular features of CloudNine’s review platform (shameless plug warning!) is the ability for the users to create their own fields – as many as they want.  This can be useful for classifying documents in a variety of ways – in many cases, using the aforementioned “tag” field.  So, the user can create their fields and organize them in the order they want to make review more efficient.  Easy, right?

Sometimes, too much of a good thing can be a bad thing.

I have worked with some clients who have used tag fields to classify virtually everything they track within their collection – in some cases, to the extent where their field collections grew to over 200 data fields!!  Try finding the data field you need quickly when you have that many.  Not easy, right?  A couple of examples where use of the tag field was probably not the best choice:

• Document Types: I have seen instances where clients have created a tag field for each type of document. So, instead of creating one text-based “DocType” field and populating it with the description of the type of document (e.g., Bank Statements, Correspondence, Reports, Tax Documents, etc.), the client created a tag field for each separate document type.  For clients who have identified 15-20 distinct document types (or more), it can become quite difficult to find the right tag to classify the type of document.
• Account Numbers: Once again, instead of creating one text-based field for tracking key account numbers mentioned in a document, I have seen clients create a separate tag field for each key account number, which can drive the data field count up quite a bit.

Up front planning is one key to avoid “playing tag” too often.  Identify the classifications that you intend to track and look for common themes among larger numbers of classifications (e.g., document types, organizations mentioned, account numbers, etc.).  Develop an approach for standardizing descriptions for those within text-based fields (that can then effectively searched using “equal to” or “contains” searches, depending on what you’re trying to accomplish) and you can keep your data field count to a manageable level.  That will keep your game of “tag” from turning into “hide and seek”.

So, what do you think?  Have you worked with databases that have so many data fields that it becomes difficult to find the right field?   Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.