Workflows
A workflow is for the work around access that is not access itself: a laptop ready three days before someone starts, a badge collected on the last day, a ticket in ServiceNow when a separation-of-duties violation is found. It lives on the Workflows page under Platform (the old Automation page and its links redirect there). The page lists every workflow with whether it is on, its last and next run and its runs in the last 30 days; opening one shows the editor with Design and Runs, and a separate view lists all runs.
A workflow never grants or removes access by writing to a target system. Access goes through a request and its approval chain, and reconciliation provisions it, so a workflow cannot open a door that the governance model would keep shut.
When a workflow starts
| Trigger | Starts |
|---|---|
| Event | On a business event from a curated list: a person created, changed, moved, deactivated, rejoined or locked out, an employment change, a request submitted, approved, rejected or provisioned, a separation-of-duties violation, a risk score turning critical, an orphaned owner, a failed or held sync, and a custom object created or changed. An "Only when" condition narrows it. |
| Date of a person | One run per person, a number of days before or after their start or end date (at most 366 days either way). |
| Schedule per person | One run per person who matches the filter, on a schedule. |
| Manual | Only when someone presses Run now. |
The two per-person triggers start one run per person and date, never twice for the same person and date. A trigger looks three days back, so a scheduler that was down on the day still starts the run. Each one carries a cap (200 people by default, at most 1,000), and the editor counts how many people the trigger would start a run for before you save. A workflow that still has the older schedule without a person keeps it; new workflows do not offer it.
The steps
Each step has a name. A later step reads an earlier one's result as steps.<name>.<field>,
for instance the ticket number a Call system step returned.
| Step | What it does |
|---|---|
| Form | Waits for someone who may start the workflow to fill in the form's own questions. A form can also show fields of the identity the run is about, each visible, read only or hidden, and a field another writer owns (a source, a generation rule, the lifecycle) is shown read only. What sending does is set on the step: the answers stay in the run, changed fields are written to the identity (audited, and reconciliation follows), or a record of another type is created. A form never creates an identity, account, entitlement or application. A question can ask for up to five files, kept for 90 days and readable only by the people involved in the run. |
| If / then | Checks a condition; the steps under Then or Else run, and the others are skipped with the reason. |
| Choose a path | A list of options with a condition each; the first option that holds is the path taken, otherwise the Otherwise path. It replaces nested Ifs when there are more than two ways. |
| In parallel | Two to six named paths that all run. A path that waits does not hold the others. The block ends when all paths, the first path or a chosen number of paths are done; unfinished paths are skipped and their open tasks lapse. |
| For each | The same steps once for every person in a list from a form (at most 50), with that person as the subject. Only steps that never wait can sit inside. A person that fails is noted and the run goes on, unless the author chose to stop the run. |
| Wait | Holds the run for a duration, or until a date field plus or minus some days (at most 366 days). The moment is stored on the run, so a deploy does not lose it; the scheduler resumes it. |
| Task | Asks someone in the Inbox to do something: the identity itself, the person who started the run, a named person, the subject's manager, the members of a role, a person picked in an earlier form or the owner of a record. Up to four extra people can answer it, and a fallback takes it when nobody is found. The assignees get a mail. The deadline is 1 to 365 days, or a date from the run moved by some days. A task can ask its own questions, which the assignee answers together with done, approved or rejected. A rejection needs a reason, and the person who started the run can never approve or reject their own request, an administrator included. |
| Request access | Files an access request for the subject of the run. The request's approval chain decides it and reconciliation provisions it; the request shows "workflow" as its origin. This is the one way a workflow reaches access. |
| Pick a record, Update the record | Change an existing record, such as an external organisation: pick it, let a form show its fields, let a task show old and new for approval, and only then write the changed fields. If the record changed since the form was sent, the update fails and says what changed. Who may be picked follows the step's rights. |
| Call a system | Opens a ticket in a ServiceNow system you configured as a connector, and hands the ticket number and link to the steps below. There is no free URL: the call goes through the connector, so its credentials stay in the vault and the transport checks apply. A connector that runs through an agent or a tunnel is refused. |
| Send email | Sends a notification template; recipients can be paths such as the subject's manager, and the text can name results of earlier steps. |
| Set attribute | Writes a field of the person that no source manages. A field a source owns or a generation rule fills is refused, because the next sync or rule would overwrite it. A real change is audited and starts reconciliation; a write that changes nothing does nothing. |
| Generate value | Builds a value from an inline template, optionally checks it is unique and writes it. |
| Start workflow | Runs another workflow and waits for its result. Chains are checked for cycles when saved and stop at ten levels. |
A step that reports a failure fails the run, with the reason, and Retry is offered. A run that did nothing is not shown as green.
Deadlines, reminders and escalation
A task with a deadline can send its assignee a reminder some days before it. After the deadline, up to three escalation levels follow, each with a new deadline: hand the task to the manager of whoever holds it or to a role, keep waiting, or stop the run with a reason.
Whose rights a step runs with
Each workflow, and each step if it differs, runs with system rights (the default) or with the rights of the person who started the run. With the starter's rights, a step that writes to an identity (Set attribute, Generate value, a form that saves to the identity) writes only the fields that person could change by hand, and a record pick list shows only what that person may read. A run fixes these rights when it starts, so editing the workflow later never changes a run in flight. A run that nobody started (an event, a date or a schedule) cannot use the starter's rights and fails with that reason.
Stopping a run
A workflow can say when a run stops by itself: the person leaves, the date that started it moves (date triggers only), or a condition no longer holds. The scheduler checks these before it resumes a run. An administrator can also press Stop run; a reason is required, and it is written on the skipped steps and in the audit trail.
Test run
Test run runs the saved or unsaved steps for one subject and writes nothing: no request is filed, no ticket opened, no mail sent, no attribute changed. It says what each step would do, who a task would go to, and which branch an If would take.
Starter workflows
The New workflow dialog offers six templates to start from: Laptop for a new starter (a task for the manager three days before the start date), Badge back on the last day (a task for the helpdesk on the end date), Ticket for a separation-of-duties violation (a ServiceNow ticket; greyed out until a ServiceNow connector exists), Request a desk phone (a form, a task for the helpdesk and a mail when it is done), Everything ready for a new starter (IT, facility and the manager in parallel, plus a contract check for a contractor) and Request a project with a team (a form, approval by the budget holder named in it and a mail to every team member). A template creates an ordinary workflow, switched off, which you change like any other.
What changed in October 2026
- Seven step types that did nothing, only logged or offboarded people were removed, among
them
notify,flag_for_reviewandoffboard_identity; stored workflows lost them, and a workflow whose behaviour changed because of it was switched off with a note. Leavers are handled by the lifecycle, not by a workflow (see JML flows). - The script library and its Scripts tab are gone. Generate value keeps its inline template; existing scripts were written into their steps, and a workflow that could not be converted was switched off with a note.
- Every change to a workflow is recorded in the configuration history with a version, and each run records the version it ran.
- From 30 October: a form lists its own fields instead of every field of an object type, and an older form was converted to its type's fields as its own questions. Choose a path, In parallel, For each, the record steps, task questions, reminders and escalation, rights per step and stop rules were added.
What it is not
- Not a way around the approval chain. Access is requested, never written.
- Not a general integration bus. A call goes to a configured connector only, and today only to open a ServiceNow ticket.
- No file questions in an object intake. A file question works in a workflow form only; an object intake form refuses it, because an intake has no run yet to keep the file.
Further reading: