From FlexRule Wiki
Jump to: navigation, search


Workflow is a special type of flow that can go to many resumable intermediate states (i.e., Waiting, Suspended, etc.) at execution time before it goes to a completed state. This allows external actors to communicate with workflow and pass information as required before the workflow is completed on those intermediate states. A workflow may take a long time to be completed (i.e., long running business transactions).

To allow an external actor (human or computer system) to communicate with workflow in different stages, FlexRule Runtime uses different types of nodes:

  1. Pause
  2. Tasks (i.e., receive, human, etc.)

In those intermediate states, external actors (human, or system) will be able to communicate with Workflow and navigate based on the workflow model.

When a workflow goes into an intermediate state, the workflow instances will not stay loaded in memory. FlexRule tries to store the context of the instance in some storage and then keeps listening for related incoming events until it receives them. Then engine will load the workflow instance and resume it from the last step.

A workflow must support long-running processes or business transactions. That means applications must maintain contexts of workflow in different stages of execution (i.e., run or resume). So, execution contexts must be maintained in a durable storage, as a workflow may take a long time to be completed. An application should provide the relevant (latest) context to the engine when required in order to continue the Workflow (i.e., Resume).


A Workflow can be suspended temporarily during execution using a Pause step. This will put the Workflow into Suspended state. Later on, the application can Resume the workflow and it will continue the execution onward.

A workflow can have as many Pause nodes as required. These can be placed between all different types of nodes (e.g., inside loops, after/before database calls, etc.).

Pause node to put the work in temporary state (Suspended)


Tasks are an advanced type of Pause nodes. A task puts the workflow instance in Waiting state. In this state, workflow can be awoken by receiving a Signal.

Tasks can be:

  1. Sequential: waiting for one signal at a time
  2. Parallel: waiting for multiple signals

Receive Task

The Receive task allows workflow to be 'Waiting' for a signal to be received. That's the simplest form of the task.


In this use-case a workflow is waiting for one signal at a time. Like any other activity in a flow, you can link multiple Receive Tasks to each other. In this case, the workflow goes into the Waiting state multiple times, but each time one Signal can be received.

Sequential Receive Task


You can use ListenerSplit to listen to multiple signals in parallel. When an associated signal is received, workflow continues executing that path (i.e., scope)

Allowing multiple options

Waiting for multiple signals in parallel allows the application to provide options in a particular state. In the above example, the workflow goes to the Waiting state once, and will be waiting for each Approve or Reject signal.


A Timeout task allows waiting for a certain amount of time and then the workflow instance will automatically receive a signal to continue the execution.

Timeout limits amount of time workflow is waiting for either an approve or decline response

An example of this is when you want to limit the response time for a Receive Task.

Timeout node must be used in the parallel scopes between Split and Join Listeners.

Human Task

Human tasks are used in human workflows to define Work and enable the interaction of humans and systems. These automate computerised and non-computerised activities in a workflow. When a workflow reaches the Task node, it can create a WorkItem and Assign it to the participants of the Work.

Enabling the interaction of two individuals on publishing content.

Human tasks enable the modeling of complex human driven workflows:

  1. Enabling outcome driven modeling of a human interaction
  2. Defining task's Owner and Participants
  3. Assigning tasks to participants
  4. Setting tasks expiration policy
  5. Delegating tasks
  6. Defining escalation logic
  7. Allowing multi-participant interactions
  8. WorkItems application to allow working on and interaction with assigned tasks

Check details on Human Task