Automations: setup, triggers, recipes, and monitoring

Automations are rules that run automatically when something happens in Edvisor — for example emailing a new student, following up when a proposal is viewed or accepted, notifying a counsellor on a pipeline stage change, creating a task, pushing data to a webhook, or reminding before a visa or insurance policy date. This consolidated article covers the full setup flow (where to find Automations, activating the feature, building, finding, duplicating, and managing rules), a reference for the 18 available events across five areas (Students, Proposals, Enrollments, Sales, Insurance) with the 'When it runs' timing options, conditions, actions, and variables, ready-made automation recipes, and how to monitor automation runs in the logs.

Automations are rules that run by themselves when something happens in Edvisor. Each rule has an event (what starts it), optional conditions (filters), and one or more actions (what to do). This article covers where to find Automations, how to activate the feature, and how to build, find, duplicate, and manage your rules.

What it is

An automation is a rule that runs automatically when something happens in Edvisor. Each automation has:

• An event — what starts it.
• Optional conditions — filters that must be met.
• One or more actions — what to do when it runs.

Common uses:

• Send a welcome email when a new student is created.
• Notify a counsellor when a student is updated.
• Create a follow-up task when a student matches a specific nationality.
• Push student data to your own system via a webhook.
• Send a reminder before a student's visa expires.
• Follow up when a student views or accepts a proposal, or before a proposal expires.
• Create a hand-off task when a school accepts an enrollment.
• Create onboarding tasks when a sale is created.
• Nudge the counsellor when a student moves into a particular pipeline stage.
• Remind the student before an insurance policy starts or ends.

Available events

An automation is triggered by an event. There are 18 events, grouped into 5 areas. For the full detail on each one, see the Triggers, conditions, and actions reference section below.

Students

• A new student is created
• A student is updated
• A student is deleted
• It is a student's birthday
• A student's visa is about to expire

Proposals

• A proposal is created
• Proposal Issued — issued or sent to the student. Previously called Proposal Published; renamed to match the rest of the product.
• Proposal Viewed — the first time the student opens the proposal, once only.
• Proposal Accepted — fires on the transition to accepted.
• Proposal expiry date — before, on, or after the day the proposal expires.

Enrollments

• A new enrollment is created for a student
• An enrollment is accepted by the school

Sales

• A sale is started
• An accommodation sale is started
• A sale is created
• Pipeline Stage Change — with Moved to stage and Moved from stage conditions. Bulk reassignments do not trigger it.

Insurance

• Policy start date
• Policy end date

Insurance events apply to confirmed bookings only.

Note: New events will be added over time, to expand the range of events that can trigger an automation.

Where to find it

Go to Settings > Recruitment > Automations.

Only admins can create, edit, enable, disable, or delete automations. Counsellors can view automations but not change them.

Activate Automations

The first time you open the Automations section, you see an activation screen explaining the feature. Activating it generates an API key pair for your account, which Edvisor uses internally to run automations. You do not need to manage the keys yourself.

After activation, you land in the Automations list view. The header shows the total count (for example, "Automations (21)"), and each automation appears as a card.

Each card shows:

• The automation name.
• The event that triggers it.
• A condition summary chip, for example "3 conditions · any", so you can see how many conditions there are and whether they use all or any logic without opening the rule.
• Action chips.
• An enable / disable toggle.
• A card menu, which is where you duplicate an automation.

Create an automation

There are two ways to start:

• From scratch — click Create automation in the top right.
• From a template — pick a template from the panel on the right side of the list view (for example, "Welcome New Student"). Templates pre-fill an event, conditions, and actions, so you only customize the details.

The builder

The builder has three parts:

• Top — Automation Name (required), Description, and an "Email me when this automation fails" toggle. Leave the toggle on to get an email whenever a run of this automation fails.
• Left panel — the rule sequence, shown as three stacked steps: EVENT > CONDITIONS > ACTIONS. Click any step to configure it.
• Right panel — the configuration for the step you selected.

You can also move forward and back through the steps with the Event / Conditions / Actions buttons at the bottom of the right panel.

When you configure the Event, you also choose when the automation runs — Instantly, or Before / On the day / After for events tied to a date (you set a duration in days). For date-based events, the builder restates the rule back to you in plain language as you build it, so you can check the timing before saving.

Click Save in the top right when you are done. Save stays disabled until all required fields are filled.

Find an automation

Once you have more than a handful of rules, use search on the Automations list to find one by name:

• Type in the search box and the list filters as you type.
• You get a result count for the matches.
• If nothing matches, you see a dedicated no-results state. This is different from the "create your first automation" empty screen, which now only appears when you genuinely have no automations at all.

Duplicate an automation

To reuse a rule instead of rebuilding it, open the card menu on the automation and choose Duplicate. It is one click.

The copy arrives switched off, and it shows a banner telling you so. This is deliberate: nothing runs until you have reviewed it. Open the copy, edit the name and whatever else needs to change, then enable it with the toggle.

Manage existing automations

From the Automations list, you can:

• Open an automation by clicking its card. This opens Edit Automation, with two tabs: Automation (the builder) and Logs (execution history).
• Enable or disable using the toggle on the card. Disabled automations are kept but do not run.
• Duplicate an automation from the card menu (see above).
• Delete an automation from within the edit view. Logs from past runs are kept.

Language

Automations are fully translated into 22 languages and follow your account language.

Triggers, conditions, and actions reference

This is the reference for the building blocks you use to build an automation: the event that starts it, the conditions that decide if it runs, and the actions it performs.

What it is

Every automation is made of three parts:

• Event — the thing that happens in Edvisor that starts the automation (for example, a new student is created).
• Conditions (optional) — extra rules that must be true for the automation to run.
• Actions — what the automation does when it runs (for example, send an email).

You choose these in the automation builder. This section lists every option you can pick.

Events

An event is the trigger that starts an automation. There are 18 events, grouped into 5 categories: Students, Proposals, Enrollments, Sales, and Insurance.

Students (5 events)

• A new student is created
• A student is updated
• A student is deleted
• It is a student's birthday
• A student's visa is about to expire

Proposals (5 events)

• A proposal is created
• Proposal Issued — the proposal is issued or sent to the student. This event was previously called Proposal Published; it has been renamed to match the rest of the product.
• Proposal Viewed — the first time the student opens the proposal. It fires once only, and never again on later views.
• Proposal Accepted — fires on the actual transition to accepted. If a student accepts option A and then option B, that is one event, not two.
• Proposal expiry date — date-based. It can run before, on, or after the day the proposal expires.

Enrollments (2 events)

• A new enrollment is created for a student
• An enrollment is accepted by the school

Sales (4 events)

• A sale is started
• An accommodation sale is started
• A sale is created
• Pipeline Stage Change — a student moves between stages in a pipeline. You choose the stages with the Moved to stage and Moved from stage conditions (see Conditions below). Bulk reassignments do not trigger this event.

Insurance (2 events)

• Policy start date
• Policy end date

Both Insurance events are date-based, and they apply to confirmed bookings only — a policy on an unconfirmed booking will not trigger them.

Note: New events will be added over time, to expand the range of events that can trigger an automation.

When it runs

For each event you set the timing:

• Instantly — the automation runs as soon as the event happens.
• Before — it runs a set number of days before a date.
• On the day — it runs on the date itself.
• After — it runs a set number of days after a date.

Date-based events (like a student's visa expiry, a proposal expiry date, or an insurance policy start or end date) ask you to enter a Duration in days for Before or After. Date-based events cannot run "Instantly", because they depend on a future date.

As you build a date-based trigger, the builder restates the rule back to you in plain language, so you can check that the timing reads the way you intended before you save.

Conditions

Conditions are optional rules that must be true for the automation to run.

Combining conditions

• You can combine conditions with all logic (every condition must be true) or any logic (at least one condition must be true).
• The automation's card in the list view shows a summary of what you set, for example "3 conditions · any".
• The same field can be used more than once in one automation, so you can build ranges and multi-part rules from a single field.

Field types

Alongside the original list-style fields, conditions now support:

• Date fields.
• Text fields.
• Yes/no fields.

Known condition fields

• Student Nationality — with operators such as "is any of". For example, run an automation only for students of a specific nationality.
• Insurance destination country — for insurance-related rules.
• Insurance provider — for insurance-related rules.
• Moved to stage and Moved from stage — used with the Pipeline Stage Change event. The pickers list the available pipelines and their stages, so you choose the pipeline first and then the stage.

Recent changes

• Two proposal conditions that were previously hidden are now available. They were not named in the release notes, so check the condition picker on a proposal event for the current list.
• One operator has been retired because it never made sense for the field it applied to. It was not named in the release notes. If you cannot find an operator you used before, this is the likely reason — reopen the condition and pick the closest remaining operator.

Actions

Actions are what the automation does when it runs. You can add more than one. Actions run one after another and each runs independently — if one action fails, the others still run.

Actions are grouped into two categories.

Communication

• Email student — sends an email to the student. The student's email is filled in automatically. You set the Subject and Body (both required), and you can use variables (see below).
• Email Counselor — sends an email to the student's assigned counsellor.

Integrations

• Create Task — creates a task. You set the task name, due date, and assignee.
  • Note: Variables in a task are stored as plain text and are not replaced with real values. Do not rely on variables inside a task name.
• Send Webhook — sends data to a URL you choose. You set the URL and the Payload. For safety, webhooks can only be sent to public addresses, and they follow a maximum of 5 redirects.

Variables

Variables let you insert real student and agency details into an email. When the automation runs, each variable is replaced with the real value.

Student

• Student ID
• First Name
• Last Name
• Email
• Date of Birth

Agency

• Agency Name
• Office Name

If a variable cannot be filled (for example, the student has no date of birth), the placeholder is removed from the message.

Language

The automation builder, including events, conditions, and actions, is fully translated into 22 languages and follows your account language.

Automation recipes: common setups

This section 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 section above.

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.

Monitoring automation runs

Every time an automation runs, it records a log entry. This section explains where to find those logs, what each field means, and how to read them when something goes wrong.

Automations can be started by a wide range of events — student, proposal, enrollment, sales and insurance events — so the logs for any given automation reflect whichever trigger it was built on. The fields, statuses and failure reasons below are the same regardless of which trigger fired.

What it is

A log is the record of a single automation run. Each run creates one log entry, so you can see exactly what happened, when, and whether it worked. Logs cannot be edited or deleted — they are a permanent record.

Where to find the logs

1. Go to Settings > Recruitment > Automations.
2. Open the automation you want to check.
3. On the Edit Automation screen, switch from the Automation tab to the Logs tab.

If the automation has never run, you see an empty state that says "No executions yet" with a button to view the automation configuration.

Reading the logs

The Logs view shows:

• A Status filter (for example, "All statuses") to filter runs by result.
• A counter showing how many runs are listed (for example, "Showing 12").
• One row per run.

Each log row shows these fields:

• Time — when the run happened.
• Status — the result (see below).
• Trigger — the event that started the run. This is whichever trigger the automation was built on, so it can be any available event. Examples you may see include Proposal created, Proposal Issued (previously called Proposal Published), Proposal Viewed, Proposal Accepted, Proposal expiry date, Pipeline Stage Change, and the insurance triggers Policy start date and Policy end date.
• Execution ID — a unique ID for the run (starts with "exec-"). Reference the Execution ID when reporting an issue, so the exact run can be found.
• Actions — how many actions ran, as a ratio (for example, "1/1" or "0/1 skipped").
• Duration — how long the run took.

Click a row to expand it and see details for each action in that run.

Statuses

• Success — the automation ran and all actions completed.
• Failed — the run did not complete.
• Partial Failure — some actions completed and some did not.

Where runs also appear

Automation runs also show up on the student's Recent Activities feed, so you can see automation activity from the student's profile.

Common failure reasons

If a run fails, it is usually one of these:

• The webhook returned a non-2xx response.
• The webhook URL pointed to an internal or private IP address (these are blocked).
• The webhook followed more than 5 redirects.
• A required variable could not be filled.

Why an automation might have no runs

If the Logs tab is empty when you expected entries, check whether the automation is switched on. In particular, when you Duplicate an automation from the card menu, the copy arrives switched off, with a banner on the automation saying so. A disabled automation never runs, so it produces no log entries at all until you enable it. This is the most common reason a newly duplicated automation appears to be doing nothing.

It is also worth confirming that the trigger has actually occurred and that the conditions on the automation match the records you are expecting — a run is only logged when the trigger fires and the conditions pass.

When to check the logs

Check the logs when an expected email, task, or webhook did not happen, or when someone reports that an automation is not working. The status and the expanded action details tell you which step failed and why.