One of the coolest features of Time Matters is its ability to relate data within itself. As significantly important as this functionality can be, it can also be confusing. The implementation of relationships has inadvertently contributed to Time Matters’ reputation for being complicated to understand. There are two types of relationships in Time Matters: Automatic and Specified. Let’s go inside these relationships by starting with the Automatic Relationship.

Automatic Relationships are, by definition, a linkage or connection between subordinate data types (Event, ToDo, Note, Document, etc) and  their Parent Contact and/or Matter. In database terminology this is referred to as a ONE:MANY relationship (ONE parent to MANY children). In specific terms, one Matter may have many Event or Document records assigned to it.

Automatic Relationships are the simplest to understand, especially when you consider how these relationships are managed. Automatic Relationships get their name from the implementation and methodology Time Matters uses to create and manage them.

Simply by entering the Contact and Matter on any form, an automatic relationship is created and managed by Time Matters. These entries are on all data entry forms located in “Area One” and, most notably, referred to as the “Regarding Area” as illustrated below.


Subordinate record types accept Contact and Matter entries and will create an automatic relationship with both the Contact and Matter.

Contact record types have a Matter entry that will create an Automatic Relationship between the Contact and the entered Matter.

Matter record types have a Client Contact entry that will create an Automatic Relationship between the Matter and the entered Matter.

Internally Defining the Relationships

Automatic relationships are stored in the RelateA database table. This table is completely perishable and may be recreated and maintained in the background from underlying record data. The RelateA table has only two columns: MID and SID. These columns hold the sysId (record identifier) of the Master and Subordinate records. The illustration below represents the RelateA table values of a Document record with a Contact and Matter in the regarding line. In this scenario, the Document is the Master ID (MID) and the Contact and Matters are the Subordinate IDs (SID).


RelateA table contents for a single Document record.
NOTE:  The Matter Record ID starts with A and the Contact Record ID starts with C.

In the example above, the Document record will also store the references to the Contact and Matters in the CON_ID and MAT_ID fields (respectively). In fact, these values (con_id and mat_id) are used to recreate the automatic relations table (RelateA) in the uncommon event a database has become impaired or corrupted.



Document record with field values for the Matter and Contact Record Identifiers.
NOTE: There are instances of the Matter ID being in the con_id field. This causes what is known as a “Cross-linked Identifier” which can only be repaired by altering the underlying data. Data Equity’s SharpShooter database tool will proactively identify Cross-Linked Records.

The Update Related Records Index function of Database Maintenance will process the con_id and mat_id of all record types (Contact, Matter, Event, Notes, etc) to create up to two RelateA records for each record in the database.

In Conclusion

The underlying functionality of the Automatic Relationship is arguably the most important feature in Time Matters. These elements are self-managing and (by virtue of database maintenance) self-healing. In the next installment of this series we will study the Specified Relationship, an equally important yet much more difficult feature to manage. In fact our research shows that most sites are challenged with integrity problems with their Specified Relationships.