×
Back to book

Identifying Workflow

A guide on how to identify potential uses of the Workflow behaviour.

While it may be easy to have a high-level understanding of what a behaviour can do, it can often be more difficult to actually apply that theory and be able to point to something and say "that is a workflow". This article aims to help guide you through processes and questions you can ask to establish whether what you are looking at is indeed a workflow.

The first step is being familiar with the behaviour and how it works. For a developer, this may mean knowing the technical details of how it operates, but for most people this just requires an understanding of its capabilities and limitations.

About Workflows

If you haven't already, make sure you read through the theory behind the Workflow behaviour. You will see at the top that it details a list of scenarios which the behaviour would complement, along with a list of examples where the behaviour is not suited. This is an excellent starting point to work from, and it is important that everyone, developers and non-techies alike, are familiar with this list if they want to identify the behaviour.

For techies, we do recommend that you also create a dummy project which uses the behaviour or complete the Workflow Behaviour qualification so that you can become familiar with the code's structure and understand what can be done with some customised code.

Identifying a potential workflow

In its essence, the Workflow behaviour is all about states and progressing something through them. If you can identify anything with a status or condition which changes, then you most likely have a workflow on your hands.

It can be as simple as something which moves between two different options; like our favourite Fishnatics example where a fish tank can be either clean or dirty. That being said, if it only has two or three states and no actions or consequences associated with the changes, then it doesn't need the complexity of involving a workflow.

Workflows become beneficial when you either have:

  • a set order which the states must change in, or
  • actions or triggers which need to occur when or before the state changes.

They are not helpful where:

  • There are a lot of options for a state, but no required order or flow to how they change, or
  • If there are only two states it can move between.

Sheer quantity of states is not a reason to involve the behaviour. The same functionality can be achieved by using an enum, and the more states involved in a workflow, the longer the setup will take.

Examples of Workflows

Timesheets

Consider the standard process for staff members to submit timesheets. The timesheet goes through a series of states (in a certain order) to make sure that everything has followed the correct process: Draft > Submitted > Approved / Declined. This is a fairly simple workflow, and can be handled by the Workflow behaviour in its most basic form.

  1. A timesheet is created. As part of the form, there will be a "Timesheet Status Workflow" dropdown which will default to Draft (which is the starting state).
  2. Once the sheet has been raised to a supervisor, the staff member can edit the details and change the status to Submitted.
  3. When a superior has reviewed the timesheet, they can change it to either Approved or Declined using the same dropdown.

Package Delivery

The delivery of a parcel is a process which almost all of us are intimately familiar with. The parcel is shipped and we receive a tracking number where we can see the status of our delivery, but that doesn't stop us from looking like this:

While there is a standard process which most parcels go through, there are also a series of failure or blocked statuses where the workflow might divert from the "standard" path before eventually returning the final status of Delivered.

This is an example of a workflow where a majority of the work is completed by the behaviour, but there would could
be additional custom code required to make transitions occur on a trigger (e.g. When the barcode is scanned at the final destination, it triggers the status to change from In Transit to Delivered).

Approval Paperwork

We have all gone through some kind of process where in order to get something completed, we must complete a number of forms and have certain types of documentation available before it can proceed. Processes and bureaucracy can be found in almost every business, but they all generally have some sort of status tracking at what point in the process they are up to.

This is another example where the behaviour can take you most of the way there, but custom code will be required to add in the conditional logic to ensure that a certain field has been filled out before the stage can progress.

Jira / Software Development Management Tools

The process of developing software can be a complicated and messy process, involving many states, transitions, triggers and conditions which are applied to tickets or stories in a project. The workflows that are built in these pieces of software can be very simple or incredibly complex depending on the needs of the development team. Some of the default workflows they provide are examples of workflows which our behaviour can build if augmented with custom code.