Workflow Overview

The workflow engine is one of the most powerful and customizable services provided by Platform 6. The diagram below provides a high level overview of how the workflow engine works and interacts with other built-in services.

Workflow Overview

  1. When transactions are saved and validated, the Routes service is configured to detect attributes of the transaction that make it suitable for submission to the workflow engine.

  2. The Routes service calls the workflow engine with each matching transaction passing the name of a configured workflow step and an initial workflow status.

  3. The workflow engine updates the transaction by adding an ‘active’ workflow element to it, setting its status accordingly.

  4. The workflow step is identified from its given name. The engine identifies the assignees of this workflow. By checking the organizational tree, each assignee is emailed, notifying them that a workflow task (work item) requires their attention.

  5. The workflow engine creates a workflow task adding each assignee identified to the assignees list.

  6. The portal UI displays the workflow tasks assigned to the current user. The UI allows the user to take an action as defined in the workflow step XML definition file. When a user submits an action, the results are sent to the workflow engine. Workflow tasks can be viewed at different places in the portal UI:

    • In the dedicated list that you can access via the left sidebar menu,
    • In the transactions list,
    • And in the transaction view display (double click on a transaction in the transactions list)

  7. The workflow task associated with the actioned transaction is removed (to stop other users from taking the same action)

  8. The workflow engine executes the script associated with the workflow action, updating the transaction workflow step status and action parameters. If the action is defined as final the active workflow task is closed.

  9. Otherwise the script action should save, validate and route the transaction such that it triggers the next step in the workflow.

Since the transaction is updated with the results of a configured workflow step, each transaction provides a history and/or current progress of workflow actions taken. This can therefore be presented to the user via the portal and a custom view.