Configure the elements of a process

In the process designer, double-clicking a node opens its configuration window. This page describes the settings of each node type in the Elements palette. To create, check and publish a process, see "Design a process".

Settings can only be changed on a draft. Several fields accept variables: the Insert a variable button offers the request fields and the process variables, inserted as {{token}}.

Settings common to all nodes

Node name: one label per active language.
What the requester sees:
- Status applied on pass: the business status shown on the request when it passes through this node (None — leaves the status unchanged by default). Statuses are defined with the designer's Statuses button;
- Display group and Group label: nodes that share the same key appear only once in the request's progress, under this label.

Human steps: Task, Approval, Field edit

These three types wait for a person to act. Their Configure the step window has four tabs.

Identity

the step Name;
for an Approval, the Decision mode: The first decision settles it, All must approve or A majority must approve. A unanimous or majority vote requires named validators: a team does not say how many votes are expected;
for an Approval, the Extra decision options (a Technical key and a Label shown to the validator): each one adds an exit to the node, which must be wired, and wins as soon as a single validator picks it; approved and rejected remain the only outcomes subject to the decision mode;
Actor's comment: None, Optional, Required, Required if approved or Required if rejected. This is what the person writes when completing the step, distinct from the request's comments;
Allowed passes: a guard against loops; empty = unlimited.

Recipients: who must handle the step. Four modes:

Fixed: Named users and Groups; both add up;
Truth table: columns (fields or variables) and rows; the first row whose cells all match designates the recipient. "Any" constrains nothing, "Empty" requires the absence of a value. The Fallback applies if no row matches;
Group template: a Group code template computed from the variables, then looked up among active groups. A code that cannot be found leaves the step without a recipient: the service owners then take over;
CMDB traversal: a Starting point (the requester, a named user, a user field or a CMDB item), then Traversal hops along CMDB relations.

In Fixed mode, a Per-recipient condition can restrict a user or a group to certain cases. A step with no recipient is refused at publication.

Fields

Form to fill in: a complete form, designed in the Dynamic forms module, that the person fills in to complete the step;
Request fields to recall: the fields shown, each one Read-only or Required. The scope is closed: nothing else can be changed. A Field edit must declare at least one editable field.

Deadlines

Deadline (hours): once this delay has passed since the step opened, the step is overdue and its recipients get a reminder, then a new one each time this delay elapses again, as long as the step stays open. It stays open and can still be handled: the deadline does not make it exit;
Overdue delay (hours): once this delay has passed, the step exits through the node's timeout exit, which must then be wired. If both are set, the deadline must come before the overdue delay, otherwise the reminder would never happen (publishing reports it);
Reminder template: the message sent with each reminder, picked from the list of existing message templates. If none is chosen, the shipped "workflow-step-reminder" template is used. Each reminder goes to the current recipients (people, group members, delegates), and not while the step is on hold. A template that can no longer be found stays displayed with the note "template not found", and publication reports it;
Scheduled start: None — starts right away, or an offset (from the request's start, from this step's opening, or from a form date field, chosen in Field carrying the start date), or an SQL query that returns the date. The step then only starts on the calculated date: it does not appear in work lists before then. Only the settings used by the chosen mode are shown and saved. A Field edit step has no scheduled start. The SQL query is reserved for Administrators: another designer is not offered it, and sees a query already in place without being able to change or remove it (the rest of the step saves normally).

Scheduled starts and deadlines depend on the scheduled job "SweepWorkflowSteps" (see "Design a process").

Flow

Start and End: one start per process, at least one end. An end has no outgoing transition.
Branch: routes the request according to conditions. Four modes:
- Group: conditions (Variable, Operator, Value) combined with Combine conditions with; exits true and false;
- Advanced SQL: an SQL query (returns a boolean). A {{token}} is not quoted: it is replaced by a parameter. This mode is reserved for Administrators and the query runs read-only; another designer sees the query in place but cannot change it, switch mode or remove it;
- Truth table: each combination of condition results becomes its own exit. Beyond four conditions, the diagram becomes hard to wire and to read;
- Select case: a Compared variable and a list of values; each value has its exit, and a "default" exit is always added for unexpected values.
Fork: opens several branches that move forward at the same time; it needs at least two outgoing transitions and a matching Join.
Join: gathers the branches of a Fork. Choose the Fork resynchronized, then the Wait mode: All branches, A branch threshold (with the number of Expected branches) or First to arrive.

Messages and data

Notification: sends a Message template (Templates module). Recipients are chosen with the same modes as for a step (Fixed, Truth table, Group template, CMDB traversal). You can add External addresses, separated by commas and Dynamic {{token}} recipients. For a group, Group delivery chooses between Group members and Group address. Link to a task lets the message include the {{work_url}} link of a step. A notification with no recipient is refused at publication.
Write variables: automatically writes request fields, each with a literal value or a {{token}}.
PDF generation: produces a PDF from a Body template (required), an optional header and footer, and stores it in a Target attachment field of the request.

Integration

Automated action: calls an external service.
- Called URL and Method (POST, GET, PUT, PATCH). The call is only allowed to a host on the allow-list kept in the configuration (key Workflow:OutboundAllowedHosts): without a list, no call goes out;
- Secret key: the name of the configuration key that holds the token to send, never the secret itself;
- Wait for the third party to call back and Callback deadline (minutes): the process waits for the external service to call back; a callback without a deadline is refused at publication;
- Abandon path: when the operator gives up on a failed call, Let the operator choose, Force success or Force failure;
- Outputs extracted from the response: an expected key in the response, its shape (Value, Array of values, Value + label, Array of values + label) and the target field of the request.
Linked request: opens a request on another catalog Requested service, with Fields carried over (request field → linked request field). When checked, Wait for it to close makes the process wait until the linked request is closed; unchecked, it continues at once and the link is for information only.
Script execution: runs a Script from the Script runner module, in a Version (approved), on a Target (Local, an Agent or a Machine group), with a Timeout (seconds) and Script parameters (literal value or {{token}}). The exit code, console output and error message can be copied into request fields. A script version that is no longer approved makes publication fail.
Create ticket (offered when the Service Desk is active): creates a Service Desk ticket at this step, for example to have a new employee's workstation prepared once their manager has approved.
- Ticket title and Description: free text where Insert a field… adds a request field, a process variable or the request number, link and requester; empty title: step name and request number;
- Ticket values: Category, Type (incident, request…), Impact, Urgency, Priority and Assignment group, each Default (Service Desk rules), Fixed value or From a field (the entered value is recognised by its name, ignoring case and accents);
- Ticket custom fields, each from a field or a fixed value;
- Copy the fields that feed nothing into the description and Attach the entered files to the ticket;
- Wait for the ticket to be resolved before continuing: unchecked, the process continues as soon as the ticket is created; checked, the step waits, then takes the normal output when the ticket is resolved, or the closed unresolved output if it is closed without being resolved (both outputs are required to publish). A ticket merged into another: the step waits for the target ticket.
The ticket number and link are then available to the following steps ({{field:ticket.number}}, {{field:ticket.url}}, for example in a notification). If the ticket cannot be created (Service Desk disabled…), the step is handed to the service owners, who retry or abandon it like a failed automated call.
Calendar event (offered when a calendar connector is installed, see Connect a calendar): writes an appointment into a Microsoft 365 (Outlook) or Google calendar, for example an on-site visit at the date chosen in the form.
- Calendar: Requester's calendar, A user's calendar (picked from the list) or Shared or resource calendar, or one named by a field (an address, or {{field}} for the address entered in the request);
- Title, Location and Description: free text where the {} button inserts a field or a variable; {{request.number}}, {{request.url}}, {{requester.name}} and {{requester.email}} give the request number, link and requester. An unknown field is replaced with nothing;
- Start and End (optional): a date in the YYYY-MM-DD HH:MM format, or a date field of the request; without an end, the event lasts the Duration when no end is set (minutes);
- Recurrence: none, or every N days, weeks or months, with the number of Occurrences (2 to 366);
- Time zone: the time zone of dates entered without an offset and of the recurrence, for example Europe/Paris; a meeting repeated at 9 am stays at 9 am after the daylight saving change. Empty: the server's time zone;
- Invite the requester, Other attendees and Booked resources (room, vehicle): addresses or fields, separated by commas; a resource blocks the slot in its own calendar;
- Link field and Identifier field: request fields that receive the event's opening link and identifier.
The link and identifier remain available to the following steps ({{field:calendar.event.url}}, {{field:calendar.event.id}}). If the calendar refuses the event, the step takes the Failure output when it is wired; otherwise it is handed to the service owners, who retry or abandon it. A process containing this element cannot be published until a calendar connector is configured, nor without its default output wired.

When the calendar is named by a field, the person filling in the request chooses the calendar the event is written to. Prefer a field with imposed values (list), and ask the Microsoft 365 or Google administrator to restrict the connector to the calendars concerned.

CMDB

These nodes only appear when the CMDB module is installed.

Create CMDB object: a CMDB object type, its Properties (Fixed or Variable value) and an Output variable that receives the identifier of the created object.
Edit CMDB object: the Id of the instance to edit (fixed identifier or {{token}}) and the properties checked Edit.
Delete CMDB object: the Id of the instance to delete.
Create CMDB relation: a Relation type, the Id of the source instance and the Id of the target instance.