Multi-instance

A multi-instance task runs several times within one case. Most often, this gives each user in a list their own task, for example each approver, each trip participant or each row of a dynamic table. You turn on multi-instance on the General tab in the Scheduling section with the Run as multi-instance option, or by selecting the Multiple users card for the solver.

Settings

No.FieldPurpose
1Multiple usersSolver card. It turns on the Run as multi-instance option automatically and shows the Scheduling section even outside expert mode. When you leave the card, multi-instance is turned off again.
2Solver typeFor the Multiple users card, From variable or Expert settings. With the From variable type, each instance gets the user it was created for. The hint next to the field reminds you that the task must have a variable to iterate over.
3Run as multi-instanceTurns on multi-instance. It can also be used with the Single user card.
4Iterate over variableThe variable used to create the instances. It is required for the Multiple users card.
5Task start conditionApplies to the whole multi-instance task: how many incoming links must arrive before the instances are created.

The Iterate over variable list contains all template variables. However, you can only iterate over a variable with multiple values (a list with multiple selection, for example a dynamic list of users with several users selected) or over dynamic rows. With any other variable, task activation ends with an error.

How instances are created

SettingWhat happens when the task's turn comes
Multi-instance with a variable to iterate overOne instance is created for each value of the variable. For dynamic rows, one instance per row. If the variable is empty, no instance is created and the branch after the task does not start.
Multi-instance without a variable to iterate overOne new instance is created each time an input reaches the task. This is useful for tasks that repeat in a loop where each pass should have its own record.

Each instance is a separate task with its own solver, deadline and form. In the task list and in the history, the instances are shown under the same name. The case graph shows them as a single node with a count badge.

You set the solver of an instance with the expression iterator(1) in the Reference person field of the expert settings. The Multiple users card with the From variable type sets it automatically. The expression returns the value the instance was created for: a user, an organizational unit or a role, depending on the list type.

Variables in instances

Each instance gets its own copy of the variables that have Copy to multi-instances checked in the variable settings. This way, the solver fills in their own values in the instance and does not overwrite other solvers. Conditions on links after the instance and auto-completion conditions are evaluated against the instance values.

When you save a multi-instance task, the editor checks the variables in the form. If any of them lacks the flag, it opens the Multi-instance variable settings window.

No.ElementPurpose
1SearchFilters the list of variables.
2VariableVariables in the form without the multi-instance flag. All of them are checked by default.
3ConfirmSets the Copy to multi-instances flag on the checked variables and saves the task.
4NoSaves the task without changing the variables.

Clicking the cross in the header closes the window and the task is not saved.

A variable without the flag is not shown in the instance
A variable in the form of a multi-instance task that does not have the Copy to multi-instances flag stays empty in the instance. In a test with the sample template, the instances showed only blank space in place of such fields. For this reason, you should usually choose Confirm in the Multi-instance variable settings window.

During a test run, a value filled in an instance also appeared in the case variable once the instance was completed. After both instances were completed, the case variable held the value from the instance completed last. If you need the results of all instances, collect them with an At the end calculation, for example into dynamic rows.

How instances are joined

When an instance is completed, the case continues along the outgoing links as with a regular task, but separately for each instance. On the following task, its Task start condition decides:

Condition of the following taskResult
waits for allThe following task waits until all instances and all other incoming branches have finished. This is how the instances are joined into a single next step.
waits for oneThe following task starts right after the first completed instance. To join instances, use waits for all.

Example: trip confirmation by co-travellers

The sample template “Travel request” has the task Confirm trip details:

  1. Multiple users card, solver type From variable, Iterate over variable = Co-travellers (a dynamic list of users with multiple selection).
  2. The form contains read-only trip details and the fields I confirm the trip details and Note of the co-traveller, both with the Copy to multi-instances flag.
  3. The task is followed by Final check with the start condition waits for all. The booking branch also leads into it.

In a test run, the requester selected two co-travellers. After approval, two instances of the Confirm trip details task were created, one for each of them. The Final check task started once both instances and the booking had finished. The case history shows both instances under the same name with different solvers.

Related: General task settings and solver, Scheduling: start, branching and deadline, Variable assignment and sections.

General task settings and solver

Planning: start, branching and due date
Syca (opens in a new tab)

Powered by HelpDocs (opens in a new tab)