Workflows are where a series of people need to be involved in the lifecycle of some information. This document explains the techniques you can use to configure the system to automatically manage the workflow: notifying the right people at the right time that they need to do something, and showing them the information.
To understand the basic principles, let's first look at a simple scenario where someone fills in a form, and someone else gets to see the information. We'll then add in some workflow management.
The components we'll need are:
- a Data Entry Form for the submitter to fill in,
- a Table to store the information,
- and a Query and a Custom View to display it to the receiver.
In this example the type and quantity of the fields don't matter – they are the 'payload' and don't need to be part of the workflow management.
So for our simple scenario, the submitter fills in the Data Entry Form, which add a record to the Table. The receiver can then visit a page which lists out all the records.
Now we need to add some workflow.
Normally when the submitter 'submits' the form, and it is added to the Table, the receiver will wbe able to see it straight away. However it might be better to provide the submitter with the ability to revisit and edit their form until they are satisfied with its contents, and only then show it to the receiver. The way to do this is to add a Checkbox field to the Table, and prompt the submitter to check the checkbox when they are done with editing the form for the last time.
The main change needed is then to add a criteria to the view shown to the receiver, which restricts it to showing records where the checkbox is checked.
Naturally you'll need to add the ability for the submitter to return to their record, which will need another Query, listing the records, with two criteria: one to restrict it to records owned by that user (so the submitter can't see other submitters' records) and another criteria to only show records where the checkbox is unchecked (so they can't continue to edit the record once it has been marked as done).
Now imagine the receiver is not the final recipient of the information, but just an intermediate moderator, who needs to approve the information before it is passed on, or published. They too need a separate checkbox so they can indicate their approval. And for them to be able to modify the information (and check that checkbox), they need their own Data Entry Form, which will contain all the 'payload' fields, plus their checkbox to indicate approval.
The moderator can also have extra fields they can see, which were not shown to the submitter. For example, there could be a text field where they could add comments to explain why they approved, or denied, a submission.
Branching workflow
Checkboxes provide a simple yes/no flow control, but often workflow needs further options. For example, a content approval flow might need three states: “unchecked”, “approved”, “denied”. For these a Dropdown or Radiobutton field could be used, or it might even be worth using a Record Link field, and listing the options in another Table.
Such multiple option fields allow for branching of the workflow logic, where different people get to see the record depending on the option chosen.
Naturally the flow can also be directed by the values in the 'payload' fields, not just the checkboxes etc set up for approval.
If the logic on the payload fields is complex, it may be possible to simplify things by using a Regular Expression action in the Event tree of the Data Entry Form. For example, this could search for several different phrases, and if a match is found set a simple value in another text field, which would allow subsequent views to set a simple criteria match on that, rather than re-running the regular expression.
Notifying people
So far we've just been affecting the visibility of the records to different people, but have not pro-actively notified them that a record has become available for them to view. The way to do this is to use the Events system available as part of the Data Entry Forms. Every time the record is submitted, the Event tree on the particular Data Entry Form, (and the Event tree on the underlying Table) is triggered, and will execute any actions that are configured there. The event tree can inspect the checkboxes etc to confirm the stage the record is in in the workflow, and can then send emails to the next person, or group of people, in line to receive the record.
The Events system also contains the ability to send delayed emails – which can act as reminders if the record has not been attended to in time, or to escalate the record for the attention of a supervisor.
Deleting records
The Events system can also be used to delete a record if certain criteria are met, although in most cases it will be better to leave the record there for audit purposes, but with a 'deleted' checkbox to prevent it showing to anyone (apart from auditors).
Usergroups
In the scenarios above we have described submitters, moderators, receivers and the like. There is no limit to the number of different levels, stages or categories of people who can be involved. Generally it will be better to set up different User Groups for each stage, and set email notifications to go to them, rather than named individuals, to keep the long-term management of the system easier. Individuals can of course be members of several User Groups at the same time.
