Onboarding that runs itself

Onboarding a supplier is rarely one job. You add their name, then remember to send the invite. You remember that this one is a driver, so they need the licence and vehicle questions the photographer does not. You remember to chase them at a week, and again at a fortnight. And once the certificate is in and approved, you remember to mark them cleared, so the person building Friday's roster can see it.

Every one of those is a small act of remembering, and small acts of remembering are what fall over on a busy week. Automations can carry the lot. This article is the recipe book: the triggers that fire off onboarding, the three actions that do something rather than emailing about it, and how to chain them into a sequence that takes somebody from a typed name to cleared to work without you touching it again.

It assumes you already know the basics of building a rule. Automations covers the trigger-and-actions shape, the email editor, and the review queue.

The pieces

Four things make this work, and only one of them is an email.

Triggers that fire off onboarding rather than off a date or a lead. There are twelve, listed in full in Automations. The one this article leans on hardest is Someone is added, which fires the moment you put a person on an event or portal, because that is the moment their private link comes into existence.

Send their invite sends that person their link, using the invite wording you have already saved. It is a separate action from an ordinary crew email on purpose: the invite path also stamps the date the invite went out, and that stamp is what both invite chases count from. An "invite" sent as a plain email would carry the same link but leave its recipient permanently invisible to the reminders.

Give them a section adds somebody to a conditional section, so the requests inside it appear on their link. This is the one that turns "the same pack for everybody" into "the right pack for this person".

Set their status moves their crew status on the event: Inducted, Docs verified, Cleared to work, or whatever your account calls it.

Three more actions round it out and are covered in Automations: Send crew email for anything you want to write yourself, Email an address for a compliance inbox or a site manager, and Wait for spacing a sequence out.

Recipe one: invite them the moment you add them

The shortest useful automation in the app, and probably the one to build first.

1. New automation, name it something like "Invite on add".
2. Trigger: Someone is added.
3. Add one action: Send their invite.
4. Turn it on.

That is the whole rule. From then on, typing a name onto an event or a portal sends that person their link, in your wording, without anybody pressing Send.

Two things worth knowing before you switch it on. It sends one automatic invite per person per event, ever, so taking somebody off and adding them back does not invite them a second time. That is the safe direction: removing and re-adding mints a new link, and without the guard the second add would email them again. If you genuinely want to re-send, the Send button on the event still does it.

And it is skipped rather than sent if the person has no email address on file, if an invite already went out in the last five minutes, or if your monthly email allowance is spent. Either way the reason is recorded on the run, so Recent activity at the foot of the Automations page tells you what happened.

Self-registration deliberately does not fire this trigger. Somebody arriving through a join link already has their link open in front of them, and the Self-registration trigger is the one for that path.

Recipe two: give each role its own pack

A single portal can serve several roles if the questions each role gets are gated. Build the sections first, then let a rule do the ticking.

On the event or portal, add a section to your requests (a Section block with the requests you want gated underneath it), open Limit who sees this on its row, and expand Show only for specific crew. Tick nobody yet: an empty tick list is what makes it a named-people section, and the panel will warn you that nobody can currently see it, which is exactly right. Put the driver questions under a section called Drivers, the kitchen questions under Kitchen, and so on.

Then build the rule:

1. Trigger: Someone is added.
2. Action: Give them a section, and type the section name (the field offers the names you already have).
3. Optionally, Send their invite after it, so they get the link once the section is on.

Order matters here. Put Give them a section above Send their invite and the person opens a link that already has their full pack on it. The other way round, they may open it before the section lands.

Three things about how the matching works:

• The section is matched by its title, not by an id. That is deliberate. A section belongs to one event, but an automation belongs to your whole account, so an id would pin the rule to a single portal and quietly do nothing everywhere else. Matching on the title is what lets one Drivers rule work on every portal that has a Drivers section. The trade is that renaming a section breaks the rule, so rename the rule at the same time.
• It only ever touches sections already limited to named people. If the name matches a section anybody can see, the rule leaves it alone and records a skipped run saying so. Adding one person to an open section would switch its gate on, which turns a section everyone could see into one only that person can, and doing that silently to a portal already in use is not a trade worth making.
• Matching ignores capitals, so "drivers" finds "Drivers".

Because the trigger fires for everybody you add, a rule like this needs a way to tell the drivers apart from everyone else. Two approaches work. Either run separate portals per role, each with its own section and its own rule, or use the section gates on an answer instead: ask "what are you here as?" as the first question, and gate the rest on the reply. Asking crew for documents and info covers conditional sections in full.

Recipe three: the chase ladder

Chasing is a stack of rules rather than one rule with a repeat setting, because each rung stops for its own reason.

A ladder that works for most accounts:

• Requests not completed at 7 days, emailing the crew member. Fires once per person, and never fires at all for somebody who finished on day three.
• Rejected upload not replaced at 7, again at 14, again at 21. Three automations on the same trigger with different day counts, which is how you build an escalation.
• Document expiring at 30 days, and again at 7.
• Document expired at 7 days after it lapses.

The document rungs run per document, not per person, so a supplier holding three dated certificates gets three independent chases. Replacing a file re-arms the ladder against the new one, because the replacement is a new upload.

Two rungs point at you rather than at them:

• Invite not opened at 3 days. This is not the same as the outstanding-requests chase, even though they fire around the same time. That one means "they opened it and stalled". This one means "the email never landed", which is usually a wrong address or a spam folder, and a second email to a broken address is a letter to nobody. Send this one to yourself, check the address, and re-send from the event.

Every rung on this ladder counts from the day the person was sent their link, so it's worth knowing what counts as sending it. The invite does, whether you sent it by hand or an automation did. A crew status update email does too, but only on a portal with "Include their private link" switched on, because that's the only version of it the person can actually act on. A status email without the link starts nothing, which is correct: nobody has been invited to anything yet. Crew statuses covers that setting.

• Upload not reviewed at 2 days, so a file somebody sent a fortnight ago stops sitting in your approval queue unread. Nobody can finish while a file is unreviewed, so this is your bottleneck rather than theirs. The editor will not let you add a crew email to this trigger at all, for the obvious reason.

Nine of these already exist as switchable system emails with wording written for you, so for a straightforward ladder you may not need to build anything: open Automations, find the card, set the day count, turn it on. Build your own only when you want a drip, a task, or a different recipient on top.

Recipe four: mark them cleared without remembering to

Crew statuses are the per-event flag that answers "is this person good to work". They used to be entirely manual, which meant the answer was only as current as the last person who thought to change a dropdown.

1. Trigger: Requests completed.
2. Action: Set their status, and pick the status (say, Cleared to work).
3. Optionally, Send crew email after it, telling them so.

The status change is recorded in their status history, so you can see when it moved and what moved it. Nothing happens if they already hold that status.

It does not email them. That is on purpose: the family's model is one action per thing that happens, so telling somebody is a separate email action placed after this one, where you can read the wording in the automation itself rather than hunting for it in a settings screen.

You need at least one status defined before the action offers you anything. Contacts then Crew statuses is where they live, and Crew statuses covers what they are for.

A word of caution worth stating plainly. A rule that sets a status is making a compliance claim on your behalf. "Requests completed" means they submitted everything you asked for, not that everything they submitted is any good, so wire the status to the moment that genuinely means what the status says. Document approved is often the safer trigger, because approving is a decision somebody actually made.

Recipe five: tell the person who is not a user

The account email goes to whoever owns the account, which on most teams is not the person who works the compliance queue. Email an address takes a typed address instead, so an alert can reach a shared inbox, a site manager, or an ops alias with no login here.

A common pairing:

1. Trigger: Document expired.
2. Action: Email an address, pointed at your compliance inbox, with the document name and the person merged into the subject.

Two things to know. It sends straight away with no review hold, like the other internal emails. And unlike the organizer and account emails, it counts against your monthly email allowance, because it is the only recipient in the app that can reach absolutely anybody. See Your monthly email allowance.

Putting one whole chain together

A worked example, on an onboarding portal for casual staff:

Five rules, and between them a name typed on Monday becomes an invited, packed, chased, cleared person without anybody keeping a list.

Check it before you switch it on

A rule that matches nothing looks exactly like a rule that is working, which is the single most common way an automation disappoints somebody.

Preview shows you how an email reads. Send test to me puts it in your own inbox. For a date-based rule, Show upcoming goes further and forecasts it against your real bookings, which Checking an automation will actually fire covers in full.

The onboarding triggers cannot be forecast that way, because they wait on a human action rather than on a date arriving. For those, the honest test is a live one: add yourself as a contact on a test portal with your own email address, and watch it run. Recent activity at the foot of the Automations page shows every run, what fired, for whom, and whether it sent, was skipped, or failed, with the reason on the row either way.

What this does not do

• It does not decide who is a driver. Give them a section puts somebody in a cohort you have already defined; the deciding is done by which portal you added them to, or by a gate on an earlier answer.
• It does not judge a document. Nothing here reads a certificate to see whether it is the right one. Approving is a human decision, which is exactly why Document approved is a good trigger to hang a status off.
• It does not chase forever. Each rule fires once per person, or once per document, and stops for its own reason. Build a ladder by stacking rules.
• It does not run on templates. A template event is a pattern rather than a booking, so nobody is added to one.

Related articles

• Automations is the full reference: every trigger, every action, the email editor, and the review queue.
• Asking crew for documents and info covers building the requests and the conditional sections a Give them a section action fills.
• Portals covers the dateless onboarding container most of these recipes run on.
• Crew statuses covers the per-event flag a Set their status action moves.
• Letting crew and guests register themselves covers the join links and QR codes behind the Self-registration trigger.
• Chasing expiring documents covers working the same list by hand.
• The weekly summary email is the digest of everything still waiting on you, once the chasing is automatic.
• When an automation email doesn't send is where to go when a rule ran and nothing arrived.