User tasks, automated tasks and control flow tasks have many features in common. They are presented in this section.

The most important common feature of all tasks is that each must be assigned a name, which identifies it uniquely within the process. The name has to be an identifier according to the usual XML rules for names (NMTOKEN).

Since the name is only a symbolic identifier, a task may also contain a description. Although any task may contain a description, it makes most sense for user tasks. If you want to provide localized versions of descriptions, put an identifier instead of the text itself into the description attribute in the workflow definition. In a resource bundle (.properties file, see the editor configuration in the Administrator Manual), you can map the identifier to the localized text, depending on the chosen locale.

Tasks that finish a workflow process are declared final. There has to be at least one task in a process definition, which is declared final. Only user tasks and automated tasks can be declared final.

A task refers its successor by name. Each task must either have at least one successor or be final. Forking tasks may have multiple successors. Joining task may have multiple predecessors.

Variables in the task scope define the local state of a task instance. However, task variables do not have restricted visibility. A variable in a task may be referred to from other tasks by prefixing the variable name with the task name and a dot. A variable defined in the process can be referred to by simply using its name without a prefix. For the definition of variables, see section Section 4.1.6, “Workflow Variables”.

A guard defines an expression that delays activation of a user or automated task until the expression evaluates to true. The expression is re-evaluated each time the state of process- or task instances changes or the content, name, or place of referred resources in the Content Management Server changes.

A precondition defines requirements which have to be fulfilled before the task itself is executed. A postcondition defines requirements which will be evaluated after the exit action has been executed. If more than one precondition or postcondition is provided, then the conditions are evaluated in the order specified. The result of such an evaluation operation is equivalent to define an And expression with an ordered set of conditions.

Note that violating a condition is considered an error. If you want to delay execution until a condition is true, use a guard. If you want to check a condition and allow correction of wrong data entry within a user task, use a validator (see below).