Settings

(1) Language key: A language key can be specified here. If it is defined in the dictionary, its value (matching the language in which you logged in) is used instead of the name of the state. The icon on the right can be used to select a key directly from the dictionary.

(2) Documentation URL: Here you can specify any URL that contains documentation of this state, which can be called via the icon on the right. You can also insert system constants into the URL there.

(3) Find and execute next transition automatically: If this option is used, the system immediately proceeds to the transition check as soon as this state is reached. In this case, no form (4) is used and no user interaction is necessary (recognisable by the dotted boundary line of the state).

If the first transition check is unsuccessful, it is automatically repeated cyclically, but only if a waiting time is also set and until the waiting time is exceeded (see section below). See also sections Workflow and Automated workflows (examples).

(4) Form settings: A form can be defined for each state. This is displayed for authorised users when the workflow job is in this state.

If no form is defined in a state and (3) is not set, the workflow job remains stuck in this state when it reaches it. The transition check must then be triggered externally. This behaviour can specifically be used if you want the workflow job to remain waiting in the background, so to speak. If later a certain event occurs, e.g. the run of a profile, this profile can then trigger the workflow job again. See section Interactive workflows (examples) (→ sleeping states).

Exceeded waiting time/final actions

If a waiting time is set in the state, the workflow job is ended when this time is exceeded. Before that, (local) final actions can be executed. Note: See workflow variable VAR_SYS_WF_TERMINATED.

In addition, the waiting time can be used for the immediate transition check (3) to continue checking cyclically after the initial check until the waiting time is exceeded.

(5) Max. wait time: If a value greater than 0 minutes is entered here, the workflow job terminates if it has been in this state for more than this waiting time. The global final actions will then not be executed.

Minimum: 1 minute. Maximum: Practically unlimited. For higher values, a tooltip shows you a conversion in hours/days.

(6) Final action: If this checkbox is set, (local) final actions can be executed.

(7) Documentation URL: Here you can specify any URL that contains documentation of these actions, which can be called via the icon on the right. You can also insert system constants into the URL there.

(8) Set conditions: Only if there are no conditions or if the conditions are fulfilled, the actions (9) are executed. If the conditions are not fulfilled, no actions will be executed, but the workflow job will still be terminated.

(9) Actions: The actions to be executed (profiles, other workflows , ASM entries, ETL/ELT pipelines, Content Inspectors) if the check in (8) is successful. If you use profiles, you have to distinguish between cron profiles ( time-driven ) and non-cron profiles ( event-driven ). For cron profiles, always set option Start cron profile via the context menu . This marks that the profile is only triggered and fetches its own data. Non-cron profiles get their input data from the workflow variable VAR_SYS_WF_DATA or VAR_SYS_WF_FILE (see details there). If the variables do not supply any data, the profile generates an error.

Each action by itself can be executed only once, but any number of actions can be selected, i.e. a profile MyProfile can be selected only once, but further profiles can be added. The same applies to the other action types.

If more than one action is specified, the behaviour of the action chain can be defined for the case that one of these actions fails. If an action fails and Ignore error is set, the action chain simply continues. If an action fails and Stop on error is set, the action chain terminates.

Start state

The start state is only the first state, the entry point. Otherwise, it is like a normal state (except for the round shape) and can occur in all the variations described above for normal states.

End state

A final state has no outgoing transition. The behaviour of end states is different from that of normal states.

Once an outgoing transition is present, the end state automatically becomes a normal state.

State and subsequent state

As soon as a workflow job changes to a state (when the workflow job is started or after a successfully executed transition of a predecessor state), it remains in this state until a triggered transition check finds a valid transition. The workflow job then changes to the subsequent state connected with this transition. In addition, actions may be executed.