Identifying Workflow
While it may be easy to have a high-level understanding of what an extension 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 extension 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 extension overview. You will see at the top that it details a list of scenarios which the extension would complement, along with a list of examples where the extension 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 extension.
For techies, we do recommend that you also create a dummy project which uses the extension or complete the Workflow extension course 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 extension 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 extension 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 extension. 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 extension in its most basic form.
- 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). - Once the sheet has been raised to a supervisor, the staff member can edit the details and change the status to
Submitted
. - When a superior has reviewed the timesheet, they can change it to either
Approved
orDeclined
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 extension, 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 extension 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 extension can build if augmented with custom code.
Was this article helpful?