How workflow launch works

A workflow is a process you build once. Launching turns it into running work for named people. This article covers what has to be ready before a launch is allowed, who a launch reaches, what exists the moment it completes, and how later changes to the workflow affect what is already running.

The examples use performance reviews. One-to-ones and 360 feedback launch the same way from their own pages.

The model

A workflow describes a process. It has no people in it and it does nothing on its own. Launching creates one running copy of that process for one person, and the workflow itself is untouched.

Launching for several people at once creates one running copy each, grouped under a single reference name so you can find them together afterwards. There is no shared object that the people in a group progress through together. Each copy moves at its own pace and can be cancelled on its own.

What has to be ready

Four things are checked, and a launch is refused if any of them fails.

The workflow must be published. Only published workflows appear in the list you choose from, and the launch is rejected on the server as well if an unpublished one is somehow chosen.

Every form the workflow opens must be published. The launch looks up the form named on each Form item and takes only published ones. If it finds none, the launch is refused rather than starting a process nobody can act on. Unpublishing a form that a live workflow depends on will therefore stop new launches, while leaving work already running alone.

The readiness check must pass. Before anything is created, the workflow is examined for configuration that cannot work, such as an item that writes goal scores when no score field exists to read them, or a set of routes where nothing ever ends. Findings are split in two. Blocking findings stop the launch and are listed on the page. Advisory findings are shown but do not stop you, because the process still runs; a skill field that no item ever applies is odd rather than broken.

The audience must not be empty. A group that currently has nobody in it counts as empty.

Who a launch reaches

You search for people or add a group, and the screen states what it is doing: Fixed at save, with the number of people “as they are now”. The groups are turned into a list of individuals at that moment, and that list is what runs.

The launch page lets you add named people, a department, a location, a job title, a company, or a manager’s reports. There is no single “everybody” option.

Three parts of Learnient decide an audience, and no two do it the same way. This is the single most common source of surprise in this area, so it is worth holding all three in view:

	How the audience is decided
Launch page	One group type at a time, resolved once and frozen at launch
Launch rule	A fixed list, or criteria across department, location, company, job title and manager — re-resolved every time the rule fires
Course assignment	One OR across every dimension the course carries, plus anybody named, re-evaluated on publish

So a course assigned to a department keeps picking up new joiners; a review launched for that department does not. Somebody who joins the department the next day has no review.

Somebody who leaves the department keeps their review — unless they are archived. A department change does nothing to work already running. Archiving the person cancels it: every draft and in-progress review of theirs is set to cancelled, and the forms attached to it go with it.

What happens the moment you launch

For a single person, everything is created before the page comes back to you, and the review is in progress immediately. Its start date is the moment you confirmed.

For more than one person, the group is recorded first and the individual records are then created in the background, one after another. On a large audience the records appear over a short period rather than all at once.

The number reported back to you when the launch is accepted is the number of people you asked for, counted before any record exists. It is not a count of records successfully created.

Each running copy is pinned to the exact version of the workflow that was published when it started. That pin never moves.

Who the work goes to

Each item names who is responsible: the person the review is about, their manager, their manager’s manager, or everyone holding a named role.

For performance reviews and 360 feedback, the manager and second-level manager are worked out once, at launch, and stored. Every later item that goes to a manager goes to whoever held that relationship on launch day, even if the person has changed team since. A review of one period should be written by whoever managed the person during it, rather than by whoever the reorganisation left in place by the time the employee got round to submitting.

Other kinds of workflow look the relationship up again each time, so a message always reaches whoever holds it now.

With positions switched on, “their manager” is the lead of the position their job reports to, and every other holder of that position can also act on the item. An approval request that is already waiting stays with the person it was sent to, unless they have left that position or been deactivated, when it moves to the new lead. Performance reviews and 360 feedback are not moved: they keep the manager from launch day.

If no manager can be found for someone at launch, nothing is locked for them and the workflow’s own fallback is used when a manager item is reached. The item records why it went there.

What people are told

Launching does not send anything by itself. A message goes out only when the process reaches an item that sends one: a Notify item, or a Task or Decision that has both a message and a notification channel set on it.

A Form item sends nothing when it becomes active. If your first item is a form for the employee and you want them to hear about it, the workflow needs a Notify item that says so.

Messages that have gone out cannot be recalled. A review can be cancelled after launch, but cancelling it does not unsend anything already sent about it.

Changing a workflow that is already running

Editing a published workflow that has been launched at least once does not change what is running. A new version is created from your edit, published, and used by every launch from then on. The version in use before is kept as it was, and everything already running stays on it.

So a change made mid-cycle reaches nobody who is already part-way through. To apply a change to work in flight, cancel it and launch again on the new version.

Editing a published workflow that has never been launched is different: it is changed in place and no second version appears.

What this means for your setup

Publish the forms first, then the workflow, then launch. Each stage refuses to move without the one before it, and finding that out on the morning you meant to launch a cycle costs you the morning.

Decide the population on the day you launch, not before. Because a launch-page audience is frozen at launch, a rule about who is in scope is a rule about who was in the group on that date.

Late starters do not need a second launch — they need a launch rule. That is what rules are for: one anchored to each person’s start date fires for each of them as they reach it, without anybody launching anything. If you find yourself planning a monthly catch-up launch, you want a rule instead.

Read advisory findings even though they do not block you. A workflow that launches is not the same as a workflow that does what you meant, and the advisory list is where the difference usually shows up.

Put a Notify item wherever somebody needs to know. It is reasonable to assume that being given a form is enough to tell somebody about it, and it is not what happens.