Probation, Renewals, Expiries: The Deadlines Nobody Owns

Someone's three-month probation ended six weeks ago. Nobody said anything, so the answer is now yes.

Not a disagreement about the person. Not a hard conversation anyone ducked. A date you could have calculated on day one, and nobody was holding on the day it arrived.

Small companies collect a surprising number of these. Probation end. Fixed-term contract expiry. Work permit and right-to-work renewal, which usually needs starting sixty days early to be worth anything. A safety or security training refresh that lapses on an anniversary. The equipment you lent someone for a project that ended in March. Each one is a date derived from another date, sitting months out, belonging to no role in particular.

Why the reminder didn't work

Because a reminder is not the work.

Calendar reminders fail in a specific, repeatable order. They fire at whoever created them, who is often not whoever should act. The founder who set it in month one is not the person running probation reviews by month eighteen. They carry nothing: a notification that says "Marek probation" at 09:00 on a Tuesday leaves you to reconstruct what a probation review even involves at this company. They are set for the deadline rather than the lead time, which is fine for probation and useless for a permit renewal that has a queue in front of it. And they are invisible until they fire, so nobody can look at March and see what March is going to ask for.

Quieter, and worse: when the person who set the reminders leaves, the reminders leave with them. Nothing announces that this has happened. You find out the way you always find out.

What a deadline needs to be useful

An owner expressed as a role, not a name. "The subject's manager" survives a reorg. "Anna" does not.

A lead time, not a due date. The question is never "when is this due" but "when does someone have to start so it's done by then." Probation is a small enough job that eighty days from joining works. A visa renewal wants ninety.

A first step that is real work. Not "review probation." Something a person can open and finish: fill in this form, upload this document, pick one of these three answers.

Once you write it that way, most of these stop being reminders and turn into short pieces of work with a shape.

Probation is four jobs, not one

Probation looks like one task. It is actually four.

The employee writes a short self-review. Their manager writes one too. Neither should wait on the other, and neither should see the other's first. That is how you get an honest pair of documents instead of one document copied twice. HR then makes a decision that needs both, and the decision has three possible answers: confirmed, extended, ended.

Each answer has different work behind it. Confirmed means a letter and a payroll note. Extended means a new date, a written reason, and another review armed. Ended means a notice period, a handover, and access removal, and it means starting today rather than after the weekend.

Model that as a checklist and you get all three branches sitting in someone's list forever, two of them permanently irrelevant and slowly going overdue. Model it as a graph and only the branch you picked becomes work. The others are skipped, along with everything behind them, and the run just finishes.

Contract renewal is the same shape with the outcomes renamed. Two reviews in parallel, one decision, renewed / not-renewed / converted-to-permanent, and three different sets of follow-up work.

Where SquadBear keeps this

Processes are the module for exactly this class of problem. A process has a trigger, a set of actions, and dependencies saying which action waits for which.

There are four trigger kinds, and two of them are the ones this post is about. A date trigger fires a number of days from the person's start date. 80 days after joining opens the probation review. A recurring trigger fires every year on their joining anniversary, which is how annual security training stops being a January wall and becomes a trickle nobody notices. The other two are event (a hire, an offboard, a manager change, an approved long leave) and manual.

Actions name a role rather than a person: subject, manager, admin, or a pinned employee for IT or payroll. If a role cannot be resolved because the manager slot is empty or the pinned person has left, the action falls back to an admin and the run records that it did. Nothing is ever assigned to nobody, and nothing is ever silently assigned to the person it is about.

A Decision action is the branching one. You write your own outcomes, two to six of them, and steps behind them carry an Only run if… condition. When the answer lands, the matching branch opens and the losing branches are skipped all the way down. Skipped work never reaches an Inbox and never goes overdue. The Probation review preset ships this shape (parallel self and manager review, an HR decision waiting on both, three conditional branches) and you can edit it rather than draw it.

Two details that matter the first time you turn one on. Date triggers arm one occurrence at a time and skip anything already in the past, so switching on "80 days after joining" does not open a review for everyone hired in the last three years. If you do want those people, activate with backfill and each gets exactly one occurrence dated today, at most one per person, so it cannot flood the workspace. Editing a process publishes a new version while runs already in flight keep the version they started under. You can improve the thing without rewriting work somebody is halfway through.

The Processes guide has the full trigger table, the dependency rules, and the two branching traps worth knowing before you build one.

Start free and arm one date trigger this afternoon. Probation is the one that pays for itself first.

Related reading: the onboarding checklist and the offboarding one, which are the two event-triggered cousins of everything above.