Creating an Audit Trail in a Form

Added by Lachlan Aldred, last edited by Howard Treisman on Mar 23, 2009  (view change)

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

Scenario

When more than one person is involved in a process it helps for the participants to be able to share contextual information between each other. Some of this information can be shared through viewing standard form fields, but this is limited by the form's structure. The real world is not that structured. Unexpected events constantly occur and these need to be recorded in the form as well.

As a form is assigned to multiple users, it is often necessary to keep an audit trail of who has "touched" the form, when, and what their comments where. To complicate matters, a user task, embedded inside of a loop may be performed many times. Each time it gets executed by someone there is new knowledge or experience being gained about that case. This knowledge needs to be shared amongst the users of the workflow so that they can perceive and understand the progression of the case.

Although LC Workflow automatically stores information in the database about each step that is performed, it is often more useful to embed this information directly into the form, in an "audit trail" or "history" table, where anyone who opens the form can see its history.

For example, a customer might need to be contacted in future using a temporary phone number while he or she is abroad. Little items of information like this are essential to the seamless customer experience workflow always promises. So how would we record these additional pieces of information into the form?

What we want to avoid is that participants in a workflow start passing notes and emails to each other, circumventing the process in the ES system. The question then is how to add snippets of information like this into the user forms so that the author date and data can be easily viewed by the next user?

In this scenario we have a new employee being started in the company. The supervisor begins a process instance by using entering data about the new employee into the initial form. The next step is to create that new employee's email address and add the created email address into the form.

A real process would be much longer than this however for purposes of expediency we stop there.

The Process

Below we see a toy-example form containing an address block, a Name|Date|Comment table and a text block for entering new comments. We can use the Avoka TaskHistory Solution Component to pick up any new comments being entered into the New Comment text field. TaskHistory can be configured to find out who made the comment and enter that, along with the time the comment was made, into our table. This allows our collaborators to better understand any important facts about this specific case, keeping the flow of work smooth.

To begin the new employee process the supervisor fills in details about the new employee such as first name, last name, and the password the new employee wants to have.

The above form shows that the process creator (Tony Blue) has made an informal comment about the essential skills and abilities of the new employee (Susan Friend).

The first step (Lookup Creator) is used to lookup the first and last name of the process creator.

The second step (Record Comments of Process Creator) is then used to update the table in the form with the comment made by the process creator, and the name of the comment author and when the comment was made.

The results of this update to the form are visible when the user task (Create Employee Email Account) gets executed, as shown in the below screen-shot.

As shown a new comment is added during this step. This also gets added to the table in the form by a subsequent step in the process, and is shown below.

An archive file containing the process, forms, and component resources can be downloaded from here. NOTE: to run the process add a task manager endpoint to this process.