Introduction to workflows
  • 20 Nov 2022
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Introduction to workflows

  • Dark
    Light
  • PDF

Article summary

This article applies to DELIVER EMPOWER licensing

Purpose of the article

This article explains the general principles and terminology of workflows in Cooperlink.

What is a workflow?

Cooperlink has an engine that generates a succession of automated actions or for the end user (the workflow). Here, we'll look at configuring the workflow for use in document approval circuits.

Prerequisite

  • Knowledge of code, and JSON in particular, is required.

  • The workflow engine uses the card concept. Please refer to the relevant section for more information by clicking here.

  • A workspace must exist beforehand. For more information, click here.

Basic principles

A workflow is defined by a set of basic elements

  • The targetType target type. It defines the type of data model to which the workflow relates.

  • The startCard card type. It is used to allow the user to set configurable workflow values at runtime (on the fly).

  • The states. They define the macro steps for executing the workflow. Reports are always run in series (linear). The current stage of the engine is referred to as current_step.

  • The actions. These are the actions performed by the workflow engine. This can be an action performed by the Cooperlink engine or an action by the end user. For serial operations, a report contains only one action. For operations performed in parallel, a report contains multiple actions.

  • The waitFor hold actions. Automatic actions are executed successively while actions requiring user intervention are put on hold. When the wait event occurs, a decision-making process identifies the output out result and evaluates whether the workflow should continue to occur.

  • The sequences. They define the ordering of actions.

These different elements can be schematized as follows.

Cards

Cards play a vital role in building a workflow in Cooperlink. Indeed, these are used both for interactions with end users, as well as for configuring the workflow on the fly.

Start card and on-the-fly configuration

When a user starts a workflow, depending on the configuration you set, the starter card can retrieve values from project cards, workspace cards, and document cards based on field keys. This avoids multiple re-encodings and processing errors. The workflow engine will then use the values from these cards and save them to the boot card. This is a copy of values. This creates a snapshot of the data when the workflow starts.

Answer cards

Interactions with users happen through an answer card. This card is attached to a conveyor task and assigned to the user or partner. The waitFor wait action scans the filling of this answer card (or all answer cards when it is a parallel state).

Result in targetType card (document)

At each waitFor step it is possible to ask the workflow engine to save the result of the state in the target card (eg. the document card in this case) by identifying the key of the corresponding field on the target card.


Was this article helpful?