> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hr-easy.nlead.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows

> The visual engine behind approvals, checklists and process automation.

The workflow engine is the backbone for approval flows, onboarding and offboarding
checklists, feedback cycles, and process automation generally. Rather than hard-coding
each process, the platform runs them as graphs you can see and change.

## Design principle

> Workflows should be transparent and co-created. Anyone affected by a process should be
> able to see how it works.

That is the module's stated philosophy, and it is why the editor is visual and why
instance state is inspectable rather than internal.

## Anatomy

A workflow is a **graph**:

| Element     | What it is                                                                      |
| ----------- | ------------------------------------------------------------------------------- |
| Node        | A step — an approval, a notification, a task, a condition, an integration call. |
| Edge        | The transition between steps, optionally conditional.                           |
| Node config | The step's parameters — who approves, which template, what deadline.            |
| Instance    | One live run of the workflow, for one subject.                                  |
| Step state  | Per instance and node: pending, complete, or failed.                            |

Instances are started with their subject — an employee, an application, an expense
report — and advance as steps complete. A failed step is recorded as failed rather than
silently retried into oblivion, so a stuck process is visible.

## Editing

The editor is a node graph. You add steps, connect them, and configure each one.
Because a workflow change reshapes every future instance, configuration is
`ADMIN`-level (`pipeline:configure`), while running instances and completing steps is
day-to-day work.

<Note>
  Changing a workflow does not rewrite instances already in flight. They finish on the graph they
  started with — the same principle as versioned contract templates and reference-question catalogs.
</Note>

## What runs on it

<CardGroup cols={2}>
  <Card title="Onboarding and offboarding" icon="clipboard-check" href="/guides/lifecycle/preboarding-and-onboarding">
    Task checklists with owners, offsets and reminders.
  </Card>

  <Card title="Absence approval" icon="umbrella-beach" href="/guides/time-absence/leave-and-absence">
    Manager approval resolved through the org graph.
  </Card>

  <Card title="Expense approval" icon="receipt" href="/guides/finance/expenses">
    Two-level approval with return-for-correction.
  </Card>

  <Card title="Recruitment pipeline" icon="diagram-project" href="/guides/recruitment/pipeline">
    Stage effects — mails, tasks, document requests.
  </Card>
</CardGroup>

## Events

Workflows both emit and consume [events](/concepts/architecture#how-modules-talk-to-each-other).
A workflow can be started by an event — `contract.signed` starting onboarding — and
completing a step emits an event other modules can react to.

This is what keeps process wiring out of the modules themselves: the pre-boarding
orchestrator does not know the onboarding checklist exists, and vice versa.

## Auditing

Every step transition is audited: which instance, which node, who completed it, when.
For an approval flow that is the approval record.