Form workflow
Form workflows control the make up and behaviour of the application form which users are completing in order to book onto a booking item.
- 1 Overview
- 2 Transitions
- 3 Actions
- 4 States
- 5 Form
Overview
Each form workflow can be created and edited directly from the configuration section of each booking item.
Clicking the edit icon next to form workflow in the configuration section of a booking item displays the detail as to which form workflow is currently selected.
Clicking create new workflow takes you through the creation wizard in order to create and customise a new form workflow.
Workflow name | Used to help you identify a specific form workflow when there may be many created within a single booking item. |
---|---|
Who can initiate workflow | Specifies which users should be capable of taking the initial step to create a new booking. Note: Select timeline owner if you want the owner of the booking to initiate the workflow. |
First state name | The name given to the state into which a new booking will be created when initiated. |
Transitions
Transitions allow a form to move between states. Which user(s) should be capable of performing the transition, as well as any actions it should perform, can be customised during the transition editing process.
As transitions are defined the workflow overview will show in a diagram form all the states in which each booking can exist, and the transitions which allow the booking to move between states.
Actions
Each successful transition can optionally apply an action should you wish it to trigger certain behaviour within the system beyond a simple change of state. The list of available actions are shown below:
Action | Description |
---|---|
Collect payment | Creates a payment request for the amount specified within the booking option onto which this booking is attached. |
Select refund option | Allows the user performing the transition to choose from a list of refund options provided below. This DOES NOT action the refund. To action a refund please choose the "refund payments" action. |
Refund payments | Triggers a refund to be generated for any transaction(s) processed on this booking. The type and amount of refund can be chosen by specifying refund options within this action. |
Move this booking | Moves this booking to a different booking option within the same booking item. |
Confirm booking | Marks this booking as confirmed. Confirmed bookings allow you to determine which bookings are complete. |
Retract booking confirmation | Removes the confirmed booking marking. |
Ensure user is still eligible | Evaluates the eligibility settings for the booking option and ensure the owner of the booking is still eligible at the point of transition. |
Reserve seat | Reserves a seat for this booking for the amount of time specified below. Once the time expires this seat will be opened up. |
Confirm seat | Allocates a confirmed seat to this booking. |
Release seat | Removes any seat allocation for this booking and open the seat up. |
Apply user fields to profile | Applies any changes to user fields made as part of the form to the user's profile. |
Send e-mail to owner | Sends an email to the primary email address of the owner of the booking. |
Actions can be added from the options (…) menu from an individual transition.
The following shows an example of adding an email action in order to trigger an email to be sent to the owner of the booking upon a successful completion of their booking.
States
Each booking can exist in a single state at any given time. States are defined and changed when creating transitions.
Once states have been defined they can summarised from the states tab.
This tab allows for the control over which users should be capable of deleting a booking in any given state.
Use timeline owner if you wish for the owner of the booking to be the person capable of deleting this booking.
Form
The form element can be accessed from the form tab.
This area allows you to design the application form you wish users to complete during the booking process. It consists of fields which can then be assigned to each state and role to determine which users have the capability of viewing/editing each field within each state.