Workflows are an essential part of FBO One and a clear understanding of what they are and how they are used is essential to using FBO One. Wikipedia gives the following description of a workflow:
A workflow consists of a sequence of connected steps where each step follows without delay or gap and ends just before the subsequent step may begin.
Workflows exist to describe an exact sequence or flow of the steps needed to complete a task such as handling a handling order or the handling a fuel order. Each step can lead to other steps in the workflow and the conditions or events that result in such steps are called the workflow transitions. The best way to understand what workflows are all about is to see one in action. In order to do so we will see what is involved in the creation of a workflow for a handling order.
A handling order workflow
The first step in the creation of any workflow is to have a clear understanding of how exactly your business operates. If you do not have this understanding then you will have to find someone who does or interview the people who actually perform the handling order in the business right now. Another great way to get hold of this information is to work alongside the people who actually do this work and take note of what they do. Next you should be able to create a workflow diagram from their actions. If you have never created a workflow diagram, then here is how.
The five-minute guide to creating a workflow
Workflows are easy, they are simply drawings that consist of only two items:
- Blocks that indicate a workflow state.
A handling order could have these states: Requested, Confirmed, Arrived, Handled, Departed.
- The conditions or events that describe a workflow transition between workflow states.
For instance, a handling order is moved from workflow state: Confirmed to workflow state: Arrived when the Aircraft has arrived. Or the workflow state is moved from: Confirmed to Confirmed when a reconfirmation message of the handling order is received. Note that this does not really 'change' the state of the handling order, but it would create an audit log of the reconfirmation.
Creating a workflow requires a keen eye for situations and events that might occur. In the example above we have forgotten to create the workflow state Cancelled for situations where a cancellation of the handling order is received. It is your job to find out all possible states and events that occur in your business to be able to create a workflow. You will have to find all states and transitions or otherwise you might get stuck later on when the workflow is used in your business.
Next comes the fun part: drawing the workflow. Draw a block for each workflow state and draw a line with an arrow between states that have a transition. Write the name of the workflow state inside the block and put the name of the transition next to the transition lines that connect the states. Normally workflows are draw from top-to-bottom so the work 'flows' from the top of the diagram to the bottom. After you have created a workflow diagram it is a good idea to show it to your colleagues and discuss it to see if you got it right and have not missed anything.
Let's create a small example. Suppose we need to create a workflow for an arrival only handling order. The identified workflow states are: Requested, Confirmed, Arrived, Crew picked up, Handled and Cancelled
There are a quite a few workflow transitions and instead of writing them all down in a list, it is easier and clearer to create a table (also called a matrix if you still remember your high school days) and fill it as follows.
Put all workflow states across the top row but skip the first column. Next put all workflow states in the first column but this time skip the first row. It helps to use the same order of workflow states when you do this. You should end up with a table that looks like this:
|From Requested|| || || || || || |
|From Confirmed|| || || || || || |
|From Arrived|| || || || || || |
|From Crew picked up|| || || || || || |
|From Handled|| || || || || || |
|From Cancelled|| || || || || || |
We have also added the word 'from' to all workflow states in the columns and the word 'to' to the workflow states in the top row.
You probably already figured out what to do next: enter the workflow state transitions in the empty spots of the table. You will end up with something like this:
|From Requested|| || confirm handling|| || || || cancel handling|
|From Confirmed|| || reconfirm handling|| arrived|| || || cancel handling|
|From Arrived|| || undo arrival|| || crew is picked up|| || |
|From Crew picked up|| || || || || handling completed|| |
|From Handled|| || || re-open handling|| || || |
|From Cancelled|| || || || || || |
Notice how this table is a great help in considering all possible state transitions. From this table it is easy to create the workflow diagram:
Also note that the workflow has two end states which are in purple blocks. This workflow also has a single start transition as indicated by the little green circle called: new arrival only order. A workflow can only be started using such a start transition, you can not enter a workflow anywhere else. Workflows must have at least one start transition but can have more.
Workflows in FBO One
In FBO One workflows are used in several places. The most obvious place where you will encounter a workflow is when you create a handling order and work with it. The workflow of the handling order describes the steps involved in the way an order is actually handled. The user(s) that are handling the order will move through this workflow from one state to another as they are progressing through the work of the order. Of course, the user(s) can only move through the workflow that as described by the transitions of the handling order workflow.
However, the use of workflows is not restricted to handling orders only. There are several different places in FBO One where workflows are used as well and depending on the place where they are used, they have a different workflow type. In a few moments you will learn why we need to tell these different workflows apart. Here is list of some of the possible types of workflows FBO One currently knows:
Here is another example of a workflow. This one is used for a catering service, it has a single start transition and two end states:
Notice that once the catering is placed in the cooler the only possible transition is to board the catering. But what happens if the aircraft has already actually departed? The catering can not possibly be boarded anymore! This workflow does not cater (no pun intended) for that situation. The FBO One operator can now only move to the Boarded state by pretending the catering has boarded and will have to enter a note describing that the boarding has not taken place in real life. The better alternative would be to extend this workflow by adding another transition to the Cancelled state.
Workflow transitions and action screens
Workflow transitions are activated (or triggered) when an event occurs. An event can be sent to FBO One by another system (for instance, when a particular flight has arrived) or to an operator of FBO One by some other means (email, telephone, radio contact, etc). In the first case FBO One will automatically activate the workflow transition and the handling order will move from the current workflow state to the workflow state as indicated by the transition. When operators of FBO One receives the event, it is their task to manually activate the transition. In practice the activation of a workflow transition means nothing more then clicking a link.
For example, below you see a handling order in the Requested workflow state. Below the line that reads AMS-126:Requested, there are a couple of allowable transition links that the user can click in order to move the current workflow state to another one (here these links are: Confirm handling, Cancel Handling, Edit, Pay and Set Parking).
Now when the FBO One operator receives an email that confirms the handling request, he presses the 'Confirm handling' link to activate the transition that moves the handling order from the current state to state Confirmed. What happens next is that FBO One presents the user with the following screen:
This screen allows FBO One operators to supply extra information about the confirmation, send confirmation emails and more. Only when the operator presses OK, the transition will be performed and the flight will be in the Confirmed state. If the operator presses Cancel, the order will still be in the Requested state.
What is important to understand is that each workflow transition can be associated with an action screen. When the transition is activated, the associated action screen is presented to the users allowing them to enter additional information or perform other actions. Only when this action screen is successfully closed, the workflow transition is performed.
The workflow type mentioned earlier defines which action screens are available to be associated with a transition. This makes sense, as a handling order confirmation action screen is only used in the context of handling orders and not in other situations.
There are quite a lot of these action screens defined by FBO One which cover almost every need. Also, most of the actions screens can be configured to your specific situation. If you think an action screen is missing, please contact FBO One support.
Note that when no action screen is specified then the operator is still presented with a screen where a remark can be entered when the transition is activated. This is what the no action screen looks like:
Now you what actions screens are, you are probably anxious to know which screens FBO One knows. As stated before, actions screens are associated with workflow types because they only make sense for particular workflows.
Order transition actions
Service transition actions
Invoice transition actions
Fuel transition actions
Entry transition actions