There are two types of relationships in Time Matters:  Automatic and Specified. We discovered Automatic Relationships in the first article. Automatic Relationships are fairly straightforward and generally easy to understand. The addition of Specified Relationships contributes to Time Matters’ reputation for being complicated to understand. Let’s continue.

Specified Relationships are, by definition, a linkage or connection among specific data types (Contacts, Matters, Event, ToDo, Note, Document, etc.). In database terminology, this is referred to as a MANY:MANY relationship. In specific terms, one Email may have many Events or Document records assigned to it.

One of the primary distinctions between Automatic and Specified relationships is that Automatic Relationships are parented by Contacts and Matters only. This is referred to as a ONE:MANY style relationship. Specified Relationships are not limited to being parented by Contacts and Matters.  Any record can be a parent and any record can be a child (in the relationship).

What makes Specified Relationships more complicated to understand is when you consider how these relationships are created. Automatic Relationships gets its name from the implementation and methodology that Time Matters uses to create and manage them. Specified Relationships can be explicitly created or can be the result of a linked lookup field.

Explicitly Assigned Specified Relationships

There are a few ways to explicitly create Specified Relationships, the first being from the “Related” tab of any form. An example of using Specified Relationships would be to explicitly assign a Matter to a Contact or vice-versa. The uses are numerous when you consider the ability to assign Outlines to Events or ToDos to Documents, etc.

The form’s “Related” tab allows the assignment of an existing (or new) record to the underlying record on the form. This Specifically assigned record will then be displayed on the related record tab as well as reports, powerviews and other areas of Time Matters that incorporate related records.

A quicker way to Specifically Relate records is by dragging and dropping them on top of each other from the main lists. This method is a very quick way to mass several related records without having to open forms and manually associate records.

Implied Specified Relationships

Specified Relationships can also be created in a way that is less formal and similar to the way an Automatic Relationship is created. When fields are customized with specific lookup options (as illustrated above), Specified Relationships can be created when the form is completed.

When the “Linked Field” option is selected on the Field Links general porperties, the Linked Lookup form of a Specified Relationship is created when the form is saved.

The bidrectional arrows represent an existing Specified Relationship between the underlying record and the “looked-up” record in the entry field to the left.

In contrast, when the lookup button is displayed as an ellipse, an underlying Specified Relationship for this field does not exist. This can be easily explained if the “Linked Field” checkbox has not been selected. When this box is unchecked, a Specified Relationship will not be created.

When the field is customized with the “Linked Field” option checked, and a value exists in the field, and the button is manifested as an ellipse (as opposed to bidirectional arrows), this is said to be an orphaned or invalid relationship and must be fixed by looking up the record again.

Internally Defining the Specified Relationship

Specified relationships are stored in the RelateS database table. Unlike the RelateA table, this table cannot be rebuilt and must never be modified from outside the program. The RelateS table has only three columns: RCode, FieldNo, MID and SID. These columns hold the relationship code (rcode) or field number (fieldno), and like the RelateA table, they also hold the sysId (record identifier) of the Master and Subordinate records.

RelateS table contents for a single explicitly defined Specified Relationship between an Event and a ToDo.
NOTE:  The Event Record ID starts with E and the ToDo Record ID starts with T.

The example above illustrates an explicitly defined Specified Relationship that was created by manually adding a relationship (either from related tab or drag and drop) using the relationship code “RES”. Notice the MID/SID pairing going in both directions; there are two records created for a single explicit Specified Relationship.

RelateS table contents for a Linked Lookup defined Specified Relationship between a Matter and a Contact.
NOTE:  The Matter Record ID starts with A and the Contact Record ID starts with C.

This next example (above) is for a “Linked Lookup” specified relation exemplified by the fieldno value. This example is for a customized lookup field in the first field of Area 3 on the Matter form. The value looked up is for a specific Contact. Note that unlike the previous example, a single record is used to identify this relationship.

In Conclusion

Unlike Automatic Relationships which are much more self-managed and self-healed, Specified Relationships are known to have integrity problems. Unfortunately, the Update Related Records Index function of Database Maintenance cannot repair or clean up these relationships. In fact, Time Matters does a poor job of enforcing the integrity of Specified Relationships and therefore does not always protect the database from orphaned relationships. The most common problem is with linked lookups becoming invalid.

We have a lot of MobileTM customers using the Palm Pre and Palm Pixi. The hardware designs are pretty cool but WebOS is arguably the best Smartphone operating system to date. In addition to the touchscreen, users command the interface with simple x/y thumb gestures below the screen. Both Palm devices use this very innovative gesture area. Though not specifically analogous to, it is somewhat reminiscent of the original Palm’s graffiti area.

Possibly the biggest problem with Palm, the company, is they wasted too much time after purchasing HandSpring and the popular Treo line of Smartphones. HP has promised to increase Palm’s R&D and ramp up the marketing. Will that be enough?

HP’s first major announcement subsequent to the acquisition was the redesign of their new pad computer, the Slate. The Slate will now be based on WebOS.

Just a few days after Technolawyer declared WebOS irrelevant (4/29/2010) in the legal practice management community, we get a major shift in the industry that will hopefully bring stronger competition to the market.

I would like to invite the PracticeBetter.com followers to a new site I recently launched; Force4Law.com. Force4Law is devoted to the technology aspects of practice management "in the cloud", with a specific focus on using Salesforce.com and applications developed on the Force.com platform.

The Inaugural Post discusses the introduction to and some brief justifications for the recent successes of cloud-based computing. I then tackle what the base-line for a cloud-based Legal Practice Management (LPM) system might be, using the Force.com platform as a jumping off point. Before going further I felt the need to address a somewhat controversial topic on debunking the cost savings of cloud-computing with a suggestion that not all firms will realize a cost benefit from the cloud, at least not initially.

With the introductions out of the way we can now start discussing the fundamentals of "functionality". The opening article on functionality is arguably at the center of why cloud-computing is gaining popularity and focuses on the ubiquitous nature of applications built on the Force.com platform.

Feel free to express your opinions in the comments. I sincerely hope you'll join us in the conversation to help shape the future of LPM cloud-computing!