Planning: start, branching and due date

The Planning section on the General tab determines when the task starts, when it is due, how many preceding steps it waits for and whether completing it ends the entire case. The Task permissions and visibility section determines the task supervisor and whether the task is displayed in the history. Both sections are visible in expert mode. Planning is also displayed without it when you select the Multiple users card for the solver.

Planning is available for the types User task, Automatic task, Controlled by subprocess, Email notification and External event trigger. Event and Smart Event do not have it.

No.FieldPurpose
1Task start timingWhen the task actually starts after its turn comes. Default immediately.
2Task due dateWhen the solver must complete the task. Default none.
3Days: (dd:hh:mm) / VariableAdditional field for timing and due date. It appears depending on the selected option and is mandatory.
4Task start conditionHow many incoming links the task waits for. Default waits for one.
5Completing the task ends the entire caseOnce this task is completed, the entire case ends, even if other tasks are still active.
6Run as multi-instanceThe task runs in multiple instances. See the Multi-instance article.

Start timing and due date

Both fields offer the same options. They differ only in the first item: for timing it is immediately, for the due date none.

OptionStart timingDue date
immediately / noneThe task starts immediately.The task has no due date.
within days from case startThe task starts once the specified time has elapsed since the case was created.The due date is the specified time from case creation.
within days from possible activity startThe task starts once the specified time has elapsed since its turn came.The due date is the specified time from the task start.
from variable at startThe task starts on the date from the selected date variable. The date is read once, when the task's turn comes.The due date is the date from the variable at the moment the task starts. Later changes to the variable do not change the due date.
from variable continuouslyAs above, but the start date is recalculated when the variable changes.The due date is recalculated when the variable changes later.

In the Days: (dd:hh:mm) field, enter days, optionally hours and minutes separated by a colon: 2 is two days, 0:4 four hours, 1:12:30 one day, twelve hours and thirty minutes. For the variable options, select a date variable of the template.

A task with later timing waits as deferred. A scheduled system job starts it once the date arrives. The due date is calculated when the task starts, and the solver sees it in the task list and in the task information.

The task due date is not the case deadline
The task due date applies only to this task. The deadline of the entire case is set elsewhere, and you can pass it to a child case by mapping to the $Termín target.

Task start condition

A task starts when a link from a completed preceding task leads into it. When multiple links lead into the task, the condition determines how many of them must be fulfilled.

OptionWhen the task starts
waits for oneRight after the first fulfilled incoming link. Typical for merging alternative branches.
waits forOnce the specified number of incoming links is fulfilled. Enter the number in the Waits for: (number of inputs) field, at least 2.
waits for allOnce all incoming links are fulfilled. Used to synchronise parallel branches. A link from a multi-instance task counts separately for each of its instances, so the task waits until all instances finish.

A task without an incoming link starts immediately after the case is created.

Branching after the task

When a task is completed, the system goes through its outgoing links in order of priority. It starts all tasks reached by a link with a fulfilled condition or by a link without a condition. The default link is used only when no other link is fulfilled. Conditions are set on the links in the template graph, not on the task.

You cannot set the branching mode in version 5.19
The editor in version 5.19 does not offer a choice of branching mode. Every task branches inclusively: it continues along all links with a fulfilled condition. To choose exactly one branch, use mutually exclusive conditions, for example decision equals Approve and equals Reject.

Ending the entire case

The Completing the task ends the entire case option is suitable for final steps after which nothing else should run: a final check, a rejection or a cancellation. Without it, the case ends when no task is active.

In the sample template “Travel request”, this option is set on the Final check task, the rejection notification Notify the traveller and the Cancel the trip event.

Task permissions and visibility

No.FieldPurpose
1SupervisorWho is responsible for the task. Default Case owner.
2Display in active tasks and historyWhen you turn this option off, task records are saved in the case history as hidden and are not displayed in the history. Useful for technical tasks. On by default.
Supervisor optionWho is the supervisor
Case ownerThe case owner.
Selected userThe user from the User field.
Organizational unit managerThe manager of the unit from the Organizational unit field. Determined at the moment the task starts. If the unit has no manager, the case owner is the supervisor.

The supervisor:

  • receives the task when the solver cannot be determined, and is the default reference person of the supervisor() expression,
  • selects the solver for the Solver selected by the supervisor assignment method,
  • gets read permission for the case.

Related: General task settings and solver, Multi-instance, Automatic task completion and cancellation.

Multi-instance

Dynamic conditions: builder
Syca (opens in a new tab)

Powered by HelpDocs (opens in a new tab)