Launching a performance review

Launching turns a review workflow into running work for named people. The screen walks you through it, and the decisions that cannot be undone afterwards are worth recognising before you make them.

Where it is

Choose Admin, then Development in the left-hand menu and Performance reviews, then Launch a review.

The screen also lays out the path that got you here: shape the goals, build the form, wire the actions, choose who and when, check and launch. If any of the first three is missing, the launch will refuse rather than start something nobody can complete — see How workflow launch works.

Launching one

1. What are you launching? Choose the workflow. Only published ones appear.
2. Who is it for? Search for a person, or add a group. Everybody who will receive it is listed as you build it.
3. When should it start? Start now, or schedule for later.
4. Check the summary and launch.

The audience is fixed at save

The screen says so plainly: Fixed at save, with the number of people “as they are now”.

Adding a department adds the people in it now. Somebody who joins tomorrow is not included, and no amount of waiting will add them. Somebody who leaves the department keeps their review — unless they are archived, which cancels it.

If you are launching for a group that changes, you want a launch rule instead. A rule re-resolves its criteria every time it fires, which is the whole difference between the two. Reviews for new starters, probation reviews, anything anchored to a person’s own dates — all of those are rules, not launches.

One person or many

For a single person, the review exists by the time the page comes back to you, in progress, starting from that moment.

For several, the group is recorded first and the individual reviews are created behind it, so on a large audience they appear over a short period rather than all at once. The number you are shown is the number you asked for, not a count of records created.

What people are told

Launching sends nothing by itself. A notification goes out only where the step is a notify node, or a task step the author configured to send email.

So a review whose first step is a plain form for the employee sits waiting for somebody who does not know it exists. This is the most common reason a cycle stalls in its first week.

Cancelling

A review can be cancelled after launch. Cancelling does not unsend anything already sent about it, so people who were notified will still have that email.

Before a big cycle

Launch one first. Pick a single person, run it through, and see what they and their manager actually receive. A cycle of four hundred is an expensive place to discover that the notify step was missing.

Check the advisory findings. The readiness check lists things that do not block the launch but usually mean the workflow does not do what you meant.