loading table of contents...

Studio Developer Manual / Version 2310

Table Of Contents Transitions

The following example shows the Studio client configuration for the workflow steps of the built-in Studio Two Step Publication Workflow.


  workflowName: "StudioTwoStepPublication",

  nextStepVariable: "nextSelectedTask",

  transitions: [
      task: "Approve",
      defaultNextTask: "Publish",
      nextSteps: [
          name: "Compose",
          allowAlways: true,
          name: "Publish",
          forceCurrentPerformer: true,
      task: "Compose",
      defaultNextTask: "Approve",
      nextSteps: [
          name: "Approve",
          isAssignmentTask: true,

Example 9.104. Workflow steps configuration for the built-in 2-step publication workflow

First of all, you need to define a nextStepVariable. This denotes the process variable of the process definition into which the result of a user choice between possible next steps is written. For the CoreMedia publication workflows this is the variable nextSelectedTask. In this case the selected step directly corresponds to the follow-up task. For the CoreMedia translation workflows this is the translationAction variable. Here, some further computation happens before a follow-up task is determined.

The transitions configuration parameter of a WorkflowPlugin consists of an array of WorkflowTransitions. For each transition, three parameters can be configured:


The current task for which follow-up steps are configured.


A list of possible follow-up workflow steps. Each step is given as a WorkflowStep with the following parameters:

  • name: The name of the step. This is the value that is written to the nextStepVariable process variable if this step is chosen.

  • allowAlways: Whether the step is always allowed, no matter whether validation issues exist for example. In the example from above, going back to Compose from Approve is always possible, even if content errors exist.

  • isAssignmentTask: Whether the step is directly tied to a process definition task which can have assignees (see the following sub-section). In the example from above, when in Compose, the next step Approve corresponds to the Approve task from the process definition and this task is one for which assignees may be set.

  • forceCurrentPerformer: Whether the step is directly tied to a process definition task for which the same performer as for the current task is forced. In the example from above, when in Approve, the next step Publish corresponds to the Publish tasks from the process definition which has to be carried out by the same performer as for the Approve task.


The default next step from the list of nextSteps. This parameter is mainly important for one case: If a task is accepted in the Workflow App and the Next Workflow Step dialog is opened, a validation immediately starts with this default step as a validation parameter so that the user does not need to explicitly select a next step to trigger a validation.



Currently, it is only possible to define next step configurations in the form of a WorkflowTransition for tasks of a running workflow. On workflow start, selecting from multiple next steps is currently not supported. So you always need one first user task from where on several follow-up steps are possible.

Search Results

Table Of Contents

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.