Workflow automates business processes. For example, in Admissions, workflows can move applications to desks and folders, add clearance checks, and add document placeholders to applications. Workflows belong to the schemes of business entities. Workflows run on triggers and must be published to run.
Business entities and schemes
Workflows belong to the schemes of business entities. Business entities, such as Application, are entities registered by the Workflow micro-service. 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. Workflows are designed using the Workflow designer.
Publishing
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.
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.