Workflows for onboarding and offboarding

A workflow says what happens after someone submits a request form. For example, one Employee onboarding request becomes a contract task for HR, accounts and a laptop for IT, a desk and access card for Facilities, and a first-day welcome. The requester sees one request and its progress; each team sees only its own tasks. Build workflows under Settings › Workflows.

Refresh workflows retries loading the saved workflows. A failed deletion shows an error and leaves the workflow visible; it is not treated as removed just because you clicked Delete.

Start from a ready-made workflow

Choose + Employee onboarding or + Employee offboarding, then give each task to the right team. If you don't have the matching request form yet, select Create that request form: it adds a form with the fields the workflow uses (for example Employee name, Start date, Needs a laptop). Tick Run this workflow for every … request and save.

Phases

Tasks are grouped in phases, such as *Before the start date*, *Accounts and equipment* and *First day*. A phase starts when every task in the phase before it is finished (done or cancelled); tasks in the same phase run side by side. Within a phase, a task can also wait for the task above it. A workflow without phases is a simple checklist: all its tasks can start at once.

Teams and owners

Give each task to a team, to one person, or both. A task for a team appears under My tasks for everyone in the team until someone selects Take it. When a task can start, its owner or, without an owner, everyone in its team is told by email.

Using the form's answers

• Only create this task when: for example *Needs a laptop is yes*, or *Department is Finance*. Tasks that don't apply to a request are not created; a note on the request lists what was skipped and why.
• Due relative to a date on the form: for example *3 days before Start date*, or *on Last working day* for removing access. Tasks are due at 17:00 in your service desk's time zone (Settings › Service levels). Without that date, a task falls back to its hours, or has no due date.
• Answers in the text: write {{employee_name}} or {{start_date}} in a task's title or details and it is filled in for each request. {{requested_for}}, {{requester}}, {{reference}} and {{request_type}} work in every workflow. A field the requester left empty shows as —.

Preview before you save

Under the tasks, Preview with sample answers shows exactly which tasks a request would get, for whom, by when and in which phase. Change the sample answers (for example tick *Needs a laptop*) to check each path. The preview uses the same rules as real requests.

In a request form, failed loads of the workflow, help article or connected tool choices show an error and a retry button. Your saved selection is kept; retry before choosing a replacement. Disabled connected tools are not offered for new automation.

When a workflow starts

• When the request is submitted, or, if its form needs approval, when it is approved. A declined request never starts.
• Once per request. The request moves to In progress, and a note on the case lists the tasks created and skipped.
• Changing a workflow later affects new requests only. Requests already started keep the tasks they were given; staff can still add, change or cancel tasks on a case.

Progress and finishing

On the request, staff and the requester see Progress: how many steps are done and which phase is in progress. The requester sees the phases, not your internal tasks. With Resolve the request when every task is finished ticked, finishing the last task resolves the request through the normal steps, and the requester is told. Without it, someone resolves it as usual once the tasks are done.