---
title: "Généralités sur les workflows"
slug: "introduction-to-workflows"
updated: 2022-11-20T13:56:07Z
published: 2022-11-20T13:56:07Z
canonical: "help.cooperlink.io/introduction-to-workflows"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.cooperlink.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction to workflows

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](/docs/en/en/quest-ce-quune-carte).
- A workspace must exist beforehand. For more information, [click here](/docs/en/en/creer-un-premier-espace-de-travail).

## **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.

![](https://cdn.document360.io/c21b52e3-341e-4ea9-8692-3488bd21cd8d/Images/Documentation/image-1668169120960.png)

## 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.

![](https://cdn.document360.io/c21b52e3-341e-4ea9-8692-3488bd21cd8d/Images/Documentation/image-1610143479143.png)

### 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.