---
title: How Automated Emails Work (Triggers and Schedules)
description: "This article explains how Symbiant's automated emails work, so you can choose, activate and adjust them with confidence. > **Applies to:** System administrators (`admin` role) · **Module:** Set up > Triggers, Schedules and Log viewer ## Two Kinds of Automated…"
url: "https://support.symbiant.co.uk/kb/how-automated-emails-work/"
updated: "2026-10-30"
category: Automated Email Reminders (Time Based)
---

# How Automated Emails Work (Triggers and Schedules)

This article explains how Symbiant's automated emails work, so you can choose, activate and adjust them with confidence.

> **Applies to:** System administrators (`admin` role) · **Module:** Set up > Triggers, Schedules and Log viewer

## Two Kinds of Automated Email

|  | Trigger (task-based) | Schedule (time-based) |
| --- | --- | --- |
| Fires when | A record is created, updated or deleted | At set times (the **Recurring** grid, in UTC) |
| Typical use | "New risk added", "Action assigned", "Level set to High" | "Review due tomorrow", "Action overdue" |
| Finds its records by | The record being saved | A **query** on the module |
| Where | Set up > **Triggers** | Set up > **Schedules** |

![Triggers and Schedules in the Set up menu](https://support.symbiant.co.uk/wp-content/uploads/2026/10/em-triggers-menu-e18237.png)

## Shipped Emails

Each module comes with a set of ready-made emails named `<module>-<what>-generic`, for example `register-risks-new-risk-generic` or `register-risks-risk-review-overdue-generic`. The **Info** column describes each one. They all arrive **inactive**, so nothing is sent until you choose what your organisation needs and activate it. See [Activating and Deactivating an Automated Email](https://support.symbiant.co.uk/kb/activating-and-deactivating-an-automated-email/).

> **Note:** Don't edit a shipped email heavily. If you need something different, build a copy with your company name in the name and leave the generic one inactive.

## The Function Chain

Both kinds of email are built from a **function chain** (the **ƒ chain** panel): a list of steps called interceptors that run from top to bottom. Each interceptor can use the result of the ones above it, chosen in its **Data source**. If a step finds nothing, the chain stops and no email is sent.

| Interceptor | What it does |
| --- | --- |
| **tx-check** | Triggers: continue only if the change matches, for example Level equals High |
| **tx-entity** | Triggers: load the record, **After change** (create and update) or **Before change** (delete) |
| **tx-user** | Triggers: collect the user who made the change |
| **query** | Schedules: find the records that match a condition, for example Review Date equals Tomorrow |
| **manager** | Find users with a role (for example `risk_admin`) through a user field such as Owners |
| **format-date** | Set how dates appear in the email, for example `dd MMMM yyyy` |
| **template** | Write the email (From, To, Cc, Subject, body), or a reminder tag in schedules |
| **tag-filter** / **tag-record** | Schedules: skip records already emailed, then remember the ones just emailed |
| **email** | Send the template as HTML or plain text |
| **log** | Record the email in the Log viewer |

## Who Fires a Trigger and Who Receives It

- A trigger's **Assignments (who can cause this trigger to fire)** decide whose changes fire it. They are not the recipients. Assign the root division to cover everyone.
- The recipients are set on the template's `To:` and `Cc:` lines with names, addresses or recipient codes:

| Send to | Code |
| --- | --- |
| Record owners | `{{<generic/owners}}{{sm.user/name}}, {{>generic/owners}}` |
| Record creator | `{{<created/user}}{{sm.user/name}}, {{>created/user}}` |
| Last person to change the record | `{{<modified/user}}{{sm.user/name}}, {{>modified/user}}` |
| Users with the manager interceptor's role | `{{<generic/owners}}{{<manager}}{{sm.user/name}}, {{>manager}}{{>generic/owners}}` |

- Emails sent "to the admins" use module roles such as `risk_admin`. The system `admin` role on its own doesn't receive module emails. See [How to Receive Module Specific Emails as System Admin](https://support.symbiant.co.uk/kb/how-to-receive-module-specific-emails-as-system-admin/).

## What Triggers Can and Can't React To

- Update triggers react to a field **changing to a value** (for example a Status set to Submitted), checked by **tx-check**. They don't fire on every edit.
- Saving is what fires a trigger: changing a field and cancelling sends nothing.
- Some module features depend on a schedule being active, for example re-issuing scheduled surveys or assessments (`...-scheduled-re-issuing-generic`).

## Checking What Was Sent

Set up > **Log viewer** lists the emails each automated email has logged, by log group. Search it to confirm an email went out and to whom.

![The Log viewer](https://support.symbiant.co.uk/wp-content/uploads/2026/10/em-log-viewer-df174a.png)

## If Emails Don't Arrive

1. Is the trigger or schedule **Active?**
2. For a trigger, does its **Assignments** cover the user who made the change?
3. Does the recipient have the right module role, and an email address?
4. Is there an entry in the **Log viewer**? If yes, the email left Symbiant: ask IT to check spam filtering and allow Symbiant's no-reply address.

## Related articles

- [Creating an Automated Email – When a Record is Created (Trigger)](https://support.symbiant.co.uk/kb/creating-a-trigger/)
- [Creating an Automated Email – When a Record is Updated (Trigger)](https://support.symbiant.co.uk/kb/creating-an-update-trigger/)
- [Creating an Automated Email Reminder – When a Record is Due (Scheduler)](https://support.symbiant.co.uk/kb/creating-a-schedule-record-due-scheduler/)
- [Setting up Recurring Schedules](https://support.symbiant.co.uk/kb/setting-up-recurring-schedules/)