Among practice management systems, Time Matters is unique in terms of how it stores custom field data. This translates into a unique experience backing it up and working with it.
The purpose of this article is to help you understand how Time Matters stores the data so that you understand why the backup process converts the data the way it does.
In Time Matters, all records have a classification code assigned to them. The classification code loosely corresponds the set of field names that are visible. For example, if a matter has a CCODE of PROP, it will potentially have different fields than a matter with a CCODE of WILLS.
Each record type (Contacts, Matters, etc.) has their own set of classification codes.
Internally, Time Matters does not store custom field definitions but instead stores a set of instructions that customize the view of each screen based on its record type and classification codes. As an example, the instructions might look something like this:
- For Matters, on Tab1, create a group in Position 1 named "Dependent".
- For Matters, on Tab1, inside of Position 1 ("Dependent"), create a field in SubPosition1 named "Name".
- For Matters, on Tab1, inside of Position 1 ("Dependent"), create a field in SubPosition2 named "Address 1".
- For Matters, on Tab1, inside of Position 1 ("Dependent"), create a field in SubPosition3 named "Address 2".
- For Matters, on Tab1, inside of Position 1 ("Dependent"), create a field in SubPosition4 named "City".
- For Matters, on Tab1, inside of Position 1 ("Dependent"), create a field in SubPosition5 named "State".
- ---
- For Matters, if the CCODE is LAND, relabel the group in Position 1 from "Dependent" to "Property".
- For Matters, if the CCODE is LAND, inside the "Property"(formerly "Dependent") group, relabel field in SubPosition3 from "City" to "County".
- For Matters, if the CCODE is LAND, inside the "Property"(formerly "Dependent") group, relabel field in SubPosition4 from "State" to "Value".
- ---
- For Matters, if the CCODE is THEFT, relabel the group in Position 1 from "Dependent" to "Property".
- For Matters, if the CCODE is THEFT, inside the "Property"(formerly "Dependent") group, relabel field in SubPosition4 from "State" to "Value".
When you look at the instructions above, there is something interesting you'll notice: for the LAND ("Sale of Land") CCODE, there are three instructions that essentially override the default configuration. The first instruction relabels a group of fields - this logically has the effect of meaning that all the fields inside the group should "inherit" the renaming of group. The second changes the label of a field from "City" to "County", and the third changes the field name from "State" to "Value".
For the THEFT ("Theft of Property") CCODE, the instructions also change the name of the group to "Property" and relabel "State" to "Value".
It is important to notice that, while multiple fields have the name "Property Value", they actually represent different things.
To make things more complex, Time Matters uses the exact same database columns to store the values of different fields. Dependent Name and Property Name will both occupy the same database column depending on the matter's CCODE - as will Dependent State, and LAND Property Value and THEFT Property Value.
This "Overlay" approach can make it very difficult to understand how a screen should look when reviewing the raw data in the Time Matters Database.
When thinking about the data above, we can likely agree that there should be multiple fields incorporating "Name" because they vary by their group ("Dependent Name" vs "Property Name"). We can also likely agree that that there should be two separate "Property Value" fields because they represent different things: LAND -> Property Value represents the value of a piece of real estate while THEFT -> Property Value represents the value of an item that was stolen by someone.
Over the years, we have changed the way we back up this data in order to favor a mechanism that is easily understood and manipulated by migration specialists. When we first built the Time Matters extractor, we would extract the base configuration and any deltas. While this was technically correct, it made it very difficult to reason between different uses of logically different fields that happen to have the same label. We have found that the extraction method that is easiest to understand captures a complete "View" of the custom fields for each CCODE. While this does mean there are more fields that need to be cleaned out, it also means that cleaning this data is now easier and faster because the data can be reasoned through quicker. When you see thousands of custom fields, don't fret - You'll likely be able to delete most of them anyways.
Universal Migrator also employs some additional logic depending on the record type, group type, and field type that are being processed.
When backing up contacts, the following additional logic occurs:
If an "Address Group" is encountered, the address is also extracted as an address for the Contact.
If an "Email Address" field is encountered, the field is also extracted as an Email Address for the contact.
If a "Phone Number" field is encountered, the field is also extracted as a phone number for the contact.
If a "Web Address" field is encountered, the field is also extracted as a Web Address for the contact.
In Time Matters, "Contact Picklist" fields actually contain two values: a textual display name (ie. "John Smith") and an OPTIONAL Contact ID link. This is important to know because it is possible for a Contact Picklist field to have text in it without actually being linked to a real contact and vice versa. Because of this, Universal Migrator will expand these fields/values into two: a text field/value and a picklist field/value. After the data is extracted, you can decide whether you want to keep the text, the link, or both.