Automation recipes: common setups

Last updated: September 2, 2026

Ready-made automation setups you can copy, each with the trigger to pick, when it runs, the conditions to add, suggested actions, and the pitfalls to avoid. Covers following up on proposals (viewed, accepted, expiry), reminding students about insurance policy start and end dates, and reacting to pipeline stage changes. This is a living page — more recipes are added over time as new triggers and conditions ship.

This page describes common automation setups you can build in Settings > Recruitment > Automations. Each recipe follows the same shape — what it achieves, the trigger to pick, when it runs, conditions to add, suggested actions, and what to watch out for — so you can skim to the one you need and build it in a few minutes.

More recipes will be added here over time as new triggers and conditions ship, so treat this as a growing library rather than a fixed list. If you build something useful that isn't here yet, it can be appended as another section.

For the full list of what's available, see the triggers, conditions, and actions reference linked at the bottom.

Recipe 1 — Follow up on proposals

What it achieves: Keeps proposals moving without manual chasing. You nudge the student before the proposal expires, follow up when they have looked at it but not acted, and hand off internally the moment they accept.

Trigger to pick: One automation per behaviour you want, drawn from the Proposals group:

  • Proposal Viewed — the first time the student opens the proposal.
  • Proposal Accepted — when the student accepts.
  • Proposal expiry date — a date-based trigger you can set to run before, on, or after the day the proposal expires.

When it runs:

  • Proposal Viewed fires on the student's first open of the proposal and never again on later views.
  • Proposal Accepted fires on the actual transition to accepted.
  • Proposal expiry date runs relative to the expiry date — for a nudge, set it a few days before. As you build a date-based trigger, the builder restates the rule back to you in plain language so you can confirm you picked the right offset and direction.

Conditions to add: Narrow the automation so it only fires for the students you mean — for example on Student Nationality, or on proposal fields such as destination or programme type. You can use the same field more than once in a rule if you need two tests on it, and the card shows a summary of what you built (for example "3 conditions · any"). If you want everything to match, keep the match mode set to all; use any when a single condition is enough.

Suggested actions:

  • Before expiry: email the student a reminder with a link to the proposal, and create a task for the owning counsellor to call them.
  • On acceptance: send a congratulations email, create the next-step task (deposit, documents), and notify the team via webhook or internal notification.
  • Viewed but not accepted: pair a Proposal Viewed automation with a follow-up email a set time later, or use the expiry-date nudge to cover the gap.

Watch out for: Proposal Viewed only fires on the first open — a student who reopens the proposal five times still generates one event, so don't build logic that assumes repeat views. Proposal Accepted fires once, on the transition — if the student accepts option A and then switches to option B, that is still a single event, not two, so an acceptance automation will not run again on the switch.

Recipe 2 — Remind students about insurance policy dates

What it achieves: Students get a heads-up before their insurance cover starts and before it ends, so they travel with active cover and know when to renew. It also gives your team a prompt to check documents at the right moment.

Trigger to pick: From the new Insurance category in the trigger picker:

  • Policy start date — for pre-arrival and "your cover starts soon" messages.
  • Policy end date — for renewal and expiry reminders.

When it runs: Both are date-based, so you choose before, on, or after the relevant day — for example seven days before the policy start date, or fourteen days before the policy end date. The builder restates the rule in plain language as you set it, so you can check the offset reads the way you intended before saving.

Conditions to add: Use Insurance destination country to send country-specific instructions, and Insurance provider where the wording or documents differ by provider. Combine them when you need both, and use the condition summary on the card to confirm the rule matches what you described.

Suggested actions:

  • Email the student their policy details and what to carry with them.
  • Create a task for the counsellor to confirm the student has their documents.
  • For end dates, email a renewal prompt and create a task to discuss extending cover.

Watch out for: Insurance triggers apply to confirmed bookings only. Policies attached to bookings that are not yet confirmed will not fire these triggers, so a student in a pending state gets nothing — don't rely on this recipe as your only cover check.

Recipe 3 — React to pipeline stage changes

What it achieves: Turns pipeline movement into action automatically — welcome messages when a student enters a stage, handover tasks when they progress, and internal alerts when they drop back or leave a stage.

Trigger to pick: Pipeline Stage Change.

When it runs: Whenever a student's pipeline stage changes. You then decide which changes you care about using the trigger's conditions.

Conditions to add: Use "Moved to stage" to act when a student arrives in a specific stage, and "Moved from stage" to act when they leave one. Combine the two to catch a specific transition (out of one stage and into another), and layer on other conditions — nationality, destination, programme — to keep the rule scoped to the right students.

Suggested actions:

  • Moved to a new stage: send the stage-appropriate email and create the next task for the owner.
  • Moved from an active stage backwards: notify the manager, or create a review task.
  • Any stage change: fire a webhook so your reporting or CRM stays in step.

Watch out for: Bulk reassignments do not trigger it. If stages are changed in bulk, no automation runs, so a large tidy-up or migration will look silent in the logs. Plan any bulk stage move on the assumption that follow-up emails and tasks will not be created, and handle those manually.

Related