Workflow automates the progress of applications through the decision-making process. Workflows can move applications to desks and folders, add clearance checks, and add document placeholders to applications.
New applications are initially allocated to the default desk. A workflow then runs that moves applications from international students to the desk for processing international applications.
Workflow can be set to run always or on specific events, such as:
-
Application clearance check completed
-
Application offer status changed
-
Application status changed
-
Default desk allocated
The event Default desk allocated is usually the first event used to trigger a workflow as the event Default desk allocated informs that a new application has been received. Other events can then trigger workflows when the application's status changes, the offer status changes, and so on.
The image Workflow example shows a workflow that runs when the academic clearance check has completed, which then moves applications to the Ready for review folder or the Reject recommended folder depending on whether the applications passed or failed the clearance check.
Workflow characteristics
Workflows run on triggers. For example, a custom event which runs when new applications are allocated to the default desk. Other triggers to run workflows are create, update, and delete events.
Workflows start at the initial workflow activity and end when the process reaches the final workflow activity. Activities between the initial and final activity have one or more actions. For example, to move an application to the folder Ready for review on completion of the academic clearance check.
Transitions determine the sequence of activities applied in the workflow process. A transition can be triggered automatically, by a command, or by a timer. On triggering, the transition can be applied always, conditionally, or otherwise. Otherwise means that a transition is applied when a transition for the same activity is not applied. For conditional transitions, the conditions must be true for the transition to be applied. For example, conditions check whether applicants have academic clearance.
The image Workflow activities and transitions shows a transition between activities.
Transitions and activities use parameters to identify the values they are to use. For example, which folder to use with the Move to folder action. Parameters are usually defined by the corresponding reference data.
A workflow can be identified as a sub-process, which can then be called by other workflows. A sub-process workflow is useful when you have multiple workflows that all require an identical series of activities. Instead of adding the same series of activities to each workflow, you create another workflow scheme that contains just these activities and identify it as a sub-process in the workflow designer.
Workflow design and publishing
Workflows belong to the schemes of business entities. Business entities, such as Application, are entities registered by the Workflow microservice. A business entity can have many schemes, such as Decision published, Ready for decision, and so on. Each scheme has a workflow and defines when the workflow runs, such as when an application is created. The custom events, conditions and actions available in a scheme are determined by the business entity. For example, the schemes in the Application business entity run when applications change and have custom events, conditions, and actions to update the applications. Whereas, the schemes in the Application clearance check business entity run when the applications clearance checks change and have conditions and actions for clearance check documents and tasks. The workflow is designed in the Workflow designer.
On completing the design of a workflow, you must publish the workflow for the workflow to run. Initially, when designing a workflow, the workflow has the status Unpublished. Then, on completing the design and publishing the workflow, the status is set to Published. You cannot update the design of a published workflow. Therefore, to update a workflow, you must create a new version, which then has the status Unpublished. Then, on publishing the new version, the new workflow is set to Published and the original, published version is set to Historic. You can only view historic workflows.