New-hire onboarding that runs itself

New-hire onboarding is the clearest example of a process everyone agrees matters and nobody owns. It runs well when the person who cares happens to be free, and badly the month they are busy, which is usually the month you are hiring.

A workflow fixes the ownership problem rather than the effort problem. The steps stop depending on anyone remembering them.

Write down what actually happens, including the parts that go wrong

Not the idealised version. The real one, including the step that always gets missed and the thing that cannot start until someone else does something.

You are looking for three kinds of step: things that can just happen, things that need a person to do something, and things that need someone to approve before the next step is safe. That third kind is why this is a workflow rather than a checklist.

Build it in Workflows

Open Workflows and lay the steps out in order. The two properties worth understanding before you start:

Steps are durable. If a run is interrupted, it resumes where it stopped rather than starting again, so a half-finished onboarding is not a lost one.

Approval gates pause the run. Nothing past the gate happens until a human says so, and the run waits indefinitely rather than timing out and continuing.

That second one is what makes it safe to put account creation and access grants inside a workflow at all.

Put the gate before anything you cannot undo. Creating a mailbox is reversible. Sending a welcome message to your whole company, granting production access, or telling a payroll provider about someone are not, and those are exactly the steps that should wait for a person who has checked the start date is still the start date.

Run it once with a fake hire

Before a real person depends on it, run the whole thing against a made-up starter. You are looking for the step that assumed something the previous step did not actually produce, which is the standard failure and is obvious the first time you watch it happen.

Let the employee do the parts that are writing

Most onboarding is documents: the welcome note, the first-week plan, the introduction to the team, the reading list for the role. Those are steps an employee can draft from your handbook and your existing roles.

For a new Senior Designer starting on the 3rd, draft their first-week
plan using our onboarding docs and the existing designer role.

Include who they should meet in week one and why, and what they should
read before day three. Leave anything I have not told you as [TBC].

What good looks like

The tenth hire gets the same onboarding as the first, including the week you are busiest.

The measure worth watching is the gate. If the same approval sits untouched for three days every time, that gate is on the wrong step or pointed at the wrong person, and the workflow will quietly become something people route around.

Also covers

Running any checklist-driven process the same way every time. Onboarding is the example; the mechanism is general, and everything above applies unchanged to client onboarding, month-end close, an equipment refresh, or an offboarding.

The three properties that make it worth building as a workflow rather than a document are the same in every case. Steps are durable, so an interrupted run resumes where it stopped rather than starting over. Approval gates pause indefinitely rather than timing out and continuing. And every run leaves a record of who did what and when.

The test for whether a process belongs here is narrow: does it have a step you would not want to happen unattended? If yes, it wants a workflow, because a gate is the only thing that reliably stops a sequence. If no, a scheduled job with a good prompt is simpler and you should use that instead.

The failure to watch for is the same one every time. A gate that always sits untouched for three days is on the wrong step or pointed at the wrong person, and a workflow people route around is worse than a checklist, because it looks like it is being followed.