• Increase font size
  • Default font size
  • Decrease font size

Workflows – Emphasis on Forms: Logic at Work

Written by Jeff Stouse on 17 April 2012.

Hits: 5801

Logic At work - Image 1 - Matter workflow
Practice management programs are framed in one of two approaches: generic, with the ability to be customized to a variety of areas of practice, or specialized, with the narrow focus of a specific area of practice. All firms in any area of practice have a list of custom data fields that they need to track, such as the Date of Accident for a Personal Injury practice. These custom fields (as opposed to standard data fields the program offers when it is launched) can always be added as the firm sees the need. Remember that the standard, or pre-defined, list of data fields is set; a practice management program needs the feature of custom data fields to allow the firm to capture any data not capable of being stored in the standard fields.

These custom data fields, just like standard data fields, are capable of storing different types of data such as text, numbers, and dates. A text field, for example, can also be placed on most practice management forms (the layout on the screen where the standard and/or custom fields are visible to the program’s users) as a memo field: one capable of storing large amounts of text. A field can also take the form of a checkbox (the value in the field is “on” or “off” – “yes” or “no”, or a variety of other options that different practice management programs assign to the check/no check capacity.)

Any practice management program that does not offer custom fields severely limits the functionality of that program. For example, almost every matter that a Personal Injury firm will handle involves a date field when the accident occurs (DOA). Without the capability of custom fields, this information is left in a memo field, where it is hard to search for and equally difficult to merge into documents the firm may need to generate.

The need to work with custom data has become a standard. Until now, those few programs that didn’t offer custom data fields were most likely newer, cloud-based programs that have been adding these now-standard features as quickly as they can. Standards in practice management functionality continue to grow as new programs, again mostly cloud-based, approach practice management needs from a fresh perspective.

The next standard to be enhanced involves how those fields are displayed. Custom data entry fields and a form which corresponds to the area of practice being utilized, for data entry or viewing purposes have long been the normal practice. On some practice management program’s forms these fields could only be laid out in pre-defined areas, while in other programs the custom data fields could be placed in any order in any location. Because each area of practice can sometimes require many fields, even those practice management programs that allow free-form layout, the result was often a long form filled with many custom data fields; some of which were not filled in until months after the matter was opened.

This “display all” custom data fields form design approach has become problematic as firms are developing more and more sophisticated workflows (the order in which fields are entered/completed on a form—and the actions that are designed to occur when fields have specific values entered.) The issue is that almost all of the programs the form to include all of the custom data fields from the first time it is used, regardless if those fields are really necessary at that stage of the form’s use. This makes the person performing the data entry have to skip over fields that may not be needed, or avoid putting data into the incorrect field. (The classic example of important data being placed in the wrong field is the “catch-all” use of the memo field.) The user sometimes has to search on a form which includes tens if not hundreds of fields for the “next” field in which data should be entered.

The requirement that every field on a form (from the moment it is displayed) must be displayed is a hold-over from earlier forms where the capability of NOT displaying every field simply wasn’t possible. Given the new approaches many firms have of collecting data (some data is gathered at the Intake meeting/stage, while other, more specific data is often gathered later in the process), placing fields on a form that have no need to be there makes the data entry form cumbersome and sometimes overwhelming (how many data entry forms display 50-200 fields from the very first time a data entry person starts to complete it; when in reality, only 20-30 may be realistically expected to be completed at this stage of the matter?)

The “as-needed” approach to displaying fields on a form makes more sense in today’s practice management programs. Displaying fields that are currently needed to accept the data currently being entered is quicker, cleaner and more reliable.

A relative new-comer to the practice management arena, HoudiniESQ’s functionality to Show or Hide a field or group of fields means that the firm now has control over the display of data fields on the area of practice form. This functionality (sure to be copied by other practice management programs) means that a form can begin by displaying fewer fields, but expand to display more as needed.

For example, in a Personal Injury firm matter: there are many key data fields that a firm may want to track in the case of an auto accident. Assume the following fields need to be tracked:

• Date of accident

• Client’s role: driver passenger, pedestrian, by-stander

• Driver Insured?

• Insurance company

• Policy limits

• Driver licensed?

• Driver cited?

• Owner of vehicle

• Road conditions

• Weather

Now, given the select fields listed (there are plenty more that firms choose to track), how can the ability to control fields on the form come into play? In this example the focus on data entry is what data will be collected now? If the user collecting data is talking to their client, who happened to be a passenger, then some of the above fields will not be completed. If the client happened to be the driver, then more fields can be completed. Given the different possible roles the client may fulfill, what sense does it make to display those fields when the client (as a passenger) almost certainly does not have any of the above information?

If the client is not the driver, other fields may be warranted: What was the client’s position in the car (front seat, back seat – position), Did the client try to warn the driver? Did the client do something to the driver to cause/help avoid the accident? Also, if the client is not the driver, then that person’s name and the above-listed fields need to be collected, but not all at this time.

However, if the client’s role is as the driver, then the standard insurance and driver fields will need to be completed when the client intake in performed.

So, an initial custom data entry form could look like this:

Workflows -  logic at work - Initial custom fields

Once Date of Accident and Client’s role fields are completed, the practice management program (in this case, HoudiniESQ) displays fields (Driver Licensed? Driver Insured?) that the program’s workflow and trigger functionality specifies:

 Workflows -  logic at work - workflow 2


And after even more fields are completed (specifically the field concerning the Driver’s insurance status), even more fields, pertinent to the available data, appear:

Workflows -  logic at work - worflow 2

As needed, fields are displayed through the use of triggers, a common feature found in many practice management programs. The difference is that the trigger functionality in HoudiniESQ includes the ability to Show or Hide any of the custom data fields—a feature not found in most other practice management programs. The logic to display the fields in the example above could obviously be changed depending on how each firm wants to Show or Hide the fields – it all depends on how the firm feels the display of fields best matches the workflow process their practice requires.

Another feature in HoudiniESQ’s handling of forms and workflows is the fact that the form’s manipulation of the custom data fields is . What this means is that even if a field is no longer displayed (the Hide option in its trigger functionality), the datum in that field is not lost. This gives the user the ability to go back to a previous field and select a different dropdown choice or uncheck a check box – and still not lose the data that has been previously entered.

In an area of practice such as military records, this capability gives the data entry person the ability to review what data will need to be collected, depending on which review board is involved. The person collecting the data can then give the client some advance notice on what the next steps in the matter would be and what, if any, specific data may either need to be collected or will be shared back to the client.

As another example, in a Personal Injury matter if the client decides to NOT accept a settlement offer, then the matter would go to trial. When the data entry person selects the “settlement accepted” option from a dropdown list the triggers would then display fields for: “date accepted,” “amount accepted,” and others. When the data entry person selects “trial” from the “Next step” field’s drop-down, the trigger associated with that field would then display fields for: “Trial date,” “Trial prep completed,” and others to appear on the form.

While this unique feature sets HoudiniESQ apart in the legal practice management program arena, other practice management programs such as Practice Master currently offer other workflow logic features that also are important. A specific and often-used feature is the ability to copy data from one form to another when a trigger which creates a new record, fires. This is mainly used when the workflow needs to copy the contents of one field on the originating record to a field on the new record.

Here’s a typical scenario: staff, attorneys and firms want to see all of the current important matter dates in one place, and that place is typically the matter form. In this example, if an attorney wants to see the upcoming deposition date for a matter, it would be nice to see it on the matter form. The problem is that the same attorney wants to see it on an event record on his/her calendar. Given the ability of most legal practice management programs to create a new record, such as an event, when a field (Deposition date) is completed on the matter form, the glaring omission missing in the past has been the ability to create the event record using the date from the matter date field as the date for the deposition record.

For example, if the Deposition field on the matter form is completed with the date “9/18/2013,” then the Event record created by the workflow trigger should copy that date into the date on the Event record – making “9/18/2013” the date of the deposition in the new event record. Currently, the new Event form would use the current date, and that would force the user to open/edit the new Deposition event and manually type in “9/18/2013”. Practice Master has provided this functionality, and other practice management programs will probably also be providing it as well.

Law firms have always wanted a practice management program that handles their data the way they handle it. However, since all firms practice law differently, what they really want is a generic practice management program that they can customize (as easily, quickly and inexpensively as possible.) The above examples of new features in the area of custom data fields, forms and workflows in legal practice management programs clearly show that some companies are providing the desired functionality.

For more information about HoudiniESQ, please visit http://www.houdiniesq.com- they offer a free, fully functional program as a trial; or if you are a solo attorney, you can use their product for free (no catch!) for as long as you want. HoudiniESQ is a product of LogicBit, and Frank Rivera is the CEO of that company.

For more information regarding Practice Master, please visit www.practicemaster.com. Software Technology, Inc. is the company that created Practice Master, and Brad Berlin is the CEO of that company.