Approval workflows is a platform for modelling business processes that include requests or applications, and review and approval by managers and/or other parties.
It was originally developed to support requests for external training in the US Federal Government. These requests need to be approved by several levels of management, sit in a holding pattern until the training is completed (or not), collect evidence of the training, and then, once the evidence is approved, get added to the applicant's record of learning.
All of those steps, or stages, are configurable: which form fields are shown or required, who the approvers are at each level, what happens to the application when it is submitted/approved/rejected/withdrawn, and what notifications are sent.
Note that the current state of the approval workflows functionality is Developer Preview, which means that while we are confident that it is ready to be used in production to solve real problems, we are not actively developing or extending it until we get feedback from our product teams and partners as to how it will be used.
Currently, in order to create a custom workflow you need a developer to create an approvalform plugin that defines all of the available form fields and, optionally, customises the workflow in ways that are not possible via the admin interface.
- Approval workflow: A configurable process for allowing a group of learners to apply, and get approval, for something to happen in Totara.
- Workflow type: An administrative grouping of functionally similar workflows.
- Workflow version: A particular workflow configuration, including a form version, that is used for the lifecycle of an application.
- Form: A set of field definitions for collecting data from the applicant during the course of this workflow, and a plugin interface for manipulating form data.
- Form version: The fixed form definition that is used by a particular workflow version.
- Stages: A step in the workflow that contains configuration for the following elements:
- Formviews: A subset of form fields that should be displayed/fillable/required at this stage.
- Approval levels: A sequence of approval steps that an application needs to go through to complete this stage.
- Approvers: A relationship (currently only Manager) or a set of individual users who are allowed to approve or reject applications as this stage.
- Interactions: Application events, such as submit and approve, that can be configured to trigger actions and transitions.
- Action: Something that happens elsewhere in Totara due to this interaction at this stage, e.g. 'Insert evidence into Record of Learning'.
- Transition: An application state change that happens due to this interaction at this stage, e.g. 'Move to the next Stage'.
- Notifications: Centralised notifications that should be triggered based on events at this stage.
- Assignment: Defines who is allowed to submit applications on this workflow, and who is allowed to approve those applications at the various approval levels.
- Assignment approval override: Allows the admin to deploy the same workflow to different sets of applicants, with different sets of approvers at some or all approval levels.
- Application: The form submission that the applicant and approvers are working with via the workflow. Applications are attached to the assignment that allowed the applicant to use the workflow.
- Applicant: The user who the application is about (or for).
- Workflow Approver: A role that can approve an application at the stage and approval level where they have been assigned.
- Workflow Manager: A role that can edit or approve an application at any stage of a workflow when necessary.
- Workflow Admin: A custom role that can create and administer workflows in the system or within a tenant. Site Manager is given all the capabilities required of a Workflow Admin.
High-level diagram showing how various entities relate to each other:
Technical entity relationship diagram at the database level:
This diagram shows an example of an approval workflow that you could build with the platform: