The heart of any process management system is keeping track of the state an entity is in as it progresses through the flow of the possible states. Given the diversity of possible structures, there is no standard implementation of how the ‘state’ is defined, but there is a general expectation that it will be based upon the value of the one or more fields in an entity record.

For ease of querying what state an entity is in, it is good practice to use a single state field, even if the state could be theoretically determined by reference to a combination of other fields. Consolidating the state within a single field also has performance benefits.

Transitioning an entity from one state to another therefore entails the value of the state field being changed. There are several ways of achieving this:

Data Entry Forms

Data Entry Forms are the primary component used to provide the user interface to move between state. These provide a flexible display surface on which fields can be displayed and data collected.

By using a set of different data Entry Forms, all connected to the same entity, but displayed to users at different states, the user can be given a focused experience where they are not distracted by aspect of the data that are not relevant at each stage.

Each Data Entry Form can be set with different user permissions. For example, in a support ticket application, the initial Data Entry Form where the ticket is initially submitted might be set to be visible and submittable by the Clients usergroup, or even by un-logged-in Visitors. Subsequent Data Entry Form would then be only accessible to the support Agent user group, and to their superiors.

Within Data Entry Forms there are two methods of changing state:

User field

The state field could be exposed to the user in a Data Entry Form, and the user allowed to specify the state it should be in, before submitting the form to save the changes.

The field could be a text field, but this would require the user to enter the new state precisely, so is probably not ideal.

A slightly better approach would be to use a Recordlink field, giving the user a choice of values to select from. This works well for simple scenarios, particularly if there are not many different states, and you do not care the sequence in which the flow progresses.

However normally the sequence does matter, so the user needs to be given a choice which is then transcribed into the state field, to which they do not have direct access, by an Update Field action.

User submit identifier

A Data Entry Form can have more than one submit button defined. This can be used to provide the user with a choice of action, and this used to define or influence the state the system assigns to the entity.

This approach gives more control over the states, as the user does not need to be offered the full set of states, just the ones relevant to the state the entity is currently at. Furthermore the logic in the Record Change event can determine what state to actually place the entity in next, mindful of what the user chose, but also with access to the other fields in the record that may affect the decision.

Triggered by Scheduled action

Some state changes may not be triggered directly by a user form submission, but by a scheduled event. For example, in a support desk application this can be used for process escalation if an agent has not picked up a ticket within a specified period.

Alternatives to Data Entry Forms

While Data Entry Forms are normally at the heart of a process management system, the initial trigger that creates the entity record to start the process may come from elsewhere:

• The Shopping Cart component could start a fulfilment process triggered by the order being paid for by a client.
• A Data Import component could start a process when a set of records is imported from an external source.