Defining the scope of workflows

Deciding on where to define the boundary of a workflow is more art than science however there is some outline guidance below that should aide your thinking, reduce the maintenance overhead and also provide consistency across the team/organisation.

Before diving into the details, it is worth understanding that AireFlow is a Choreographed Workflow engine. This is distinct from an Orchestrated Workflow engine in that it functions based on input cues or events (like dancers waiting to do their move based on the cues from other dancers). In this way it is very easy to create parasitic child workflows that are triggered by events on another (main) workflow without needing to alter the original workflow, and without the other main workflow being aware of the parasictic child workflow.

As an example - consider a workflow that supports a hospital-admimission process. A step in that process might be the completion of a general patient assessment form. Consider a scenario where the assement form identifies that the elderly patient being admitted has had a fall within the last 6 months - and therefore (from a clinical perspective) needs a comprehensive falls assessment.

Here we could either:

1. Extend the hospital-admimission workflow to also contain the full falls assessment steps too.
2. Define a seperate falls-assessment workflow that is triggered by the form submission event associated with the hospital-admimission workflow (provided the data indicates that an elderly patient had a fall within the last 6 months).

In general we would favour option 2 above as:

• The core hospital-admission workflow remains stable (avoiding the need to up-version), and an organisation can choose to digitise downstream activities or processes iteratively over time.
• The falls-assessment workflow becomes reusable and can also be triggered in different contexts - for instance it could also be triggered if the patient was not deemed to be at risk of falls at the time of admission, but has a fall on the ward as an inpatient.
• The hospital-admission workflow can operate without knowing or needing anything from the falls-assessment workflow and visa versa (other than the trigger event).
• The hospital-admission and falls-assessment workflows can evolve independently of each other.

Rules of thumb to define the workflow scope

When to consider a single workflow

If it is logically part of a one business process with tight coupling we would be inclined to have it as a single AireFlow workflow. i.e.

• We think of it as one end to end process (for instance imagine how people would whiteboard the process in a workshop).
• It is generally the same group of triggers and human actors involved.
• We likely want to create some visualisations across the whole flow.
• If we are making any amends or updates we are likely to want to consider the whole.

When to consider a seperate workflow

We would consider creating a seperate workflow when:

• The second workflow is parasitic on the first, and other than triggers does not have any tight coupling or dependency on the main workflow (and visa versa).
• It is likely to be reused and triggered across multiple contexts.
• It is likely to evolve independently of the parent workflow.