Concepts
States and Actions
State and Actions work together to execute your processes
A flow in Stubber is made up of states and actions.
States are the current state of a stub at a certain point in time. Think about a scenario where you were at the shop waiting at the counter to pay for your groceries. In the context of Stubber, you would be in the state of waiting-to-pay.
Actions are options available to the user in whatever state the stub might be. Using the example above the actions you have available to you in this state might be pay_with_cash, pay_with_card or storm_off_angrily.
Introduction
Templates and Stubs recap
From what we have learnt already we know that each stub is an instance of a template. Let's think of our example used in the introduction again.
A template might be defined for the process of a shopper purchasing goods from a store. Lets say that roughly the process is something like:
- Customer enters the store
- Customer chooses an item/s
- Customer pays for their items
- Customer leaves
That process or flow would be what is defined in the template.
Each customer that enters the store would be a unique participant of that process or procedure with their own details of their journey along the process. Each customer in this example would be a stub, with all their own unique information of how they moved along the process. What time they entered, what they chose, how much they paid, when they left etc.
One template => many stubs
If we look at the example below, we can see that many stubs are created from a single template, all with their own unique information about what has happened in the stub. This represents a parent-child or one-to-many type of relationship.
One stub => one state
The stub keeps track of what state it is in. Each stub can only be in one state at any point in time. One way to think of states and actions is as a finite state machine.
Each stub => its own state
Each stub can be in it's own state independently of one another. Remember that the states are defined in the template, so any stub that is created can be in any one of the states in that template. Thinking of our example of shopping again, many customers can be in the state of choosing-items at a single time and a shop can have many individual customers (stubs) inside at once.
States
We could visualize states all linking together like this. Every stub has a starting state and can move from one state to another. Think about the example of the customer shopping experience we spoke about earlier.
Stubs follow the links between states and transition between them. See the example below of sales lifecycle. Notice how states flow from state one to another, and how that a state can transition to multiple different states based on an outcome.
If we take this further and name the actions that are taken to move between states then the diagram might look something like this.
Actions
This leads us further into our understanding of the actions that are taken to move between states. Actions are the options that are available to the user in each state. Typically there are different types of actions:
Transitioning actions
These are actions that cause a stub to move from one state to another. This is how stubs move between states. In the example below, the action of capture_details of a customer always lead into the next state of quoting-in-progress.
Non-transitioning actions
These are actions that do not transition a stub from one state to another. Using the example below, the send-quote action doesn't change the fact that the we are still in the quoting-in-progress state.
Shared actions
Actions can belong or be performed from multiple states. For example in the diagram below we have a "flag enquiry" action that can be performed in multiple states. This action is "available" in multiple states.
Summary
When we put all of this together we can see how states and actions work together.
We can chain these 2 concepts together to create any process ( template) that we want. This is done on the Stubber Platform using the Editor.
Defining States and Actions
States and Actions are defined within the flow of the context.
Each flow must have a busy_start_state defined, which is the state that the (stub) will start in. When adding your first state to a flow, it will automatically be set as the busy_start_state.
The states define the periods of time in the stub.
The actions define options that are available in each state.
Linking States and Actions
There are 2 ways that states and actions can be linked together.
Availability link
If we link an action onto a state then the action is available in that state.
These links are dotted lines in the Stubber Editor.
Transition link
If we link an action to a state that indicates that the action will transition the stub to that state.
These links are solid lines in the Stubber Editor.
Action Categories
To group actions to better understand where they are used we can group actions into categories.