Email actions in triggers let you automatically send emails when certain events happen, such as a new constituent being added or a donation being received.
You can send emails to internal users or directly to the constituent involved in the trigger event, and personalise them using placeholders.
⚠️Important:
Trigger emails are sent via your Email Server Settings. If your email server is not set up and authenticated correctly, emails will not send.
Understand Email Trigger Actions
There are two email-related trigger actions:
Email User – sends an email to one or more Donorfy users.
Email Constituent – sends an email to the constituent that caused the trigger.
Both actions:
Are available for Constituent, Transaction, Activity, and RPI trigger types.
Allow you to use {Placeholders} in the subject and body so the email can be personalised with data from the trigger event.
Can be targeted using conditions based on Lists.
Email User Action
The Email User action sends an email to one or more users in your system when a trigger fires.
Typical use cases include:
Notify a fundraising manager when a large donation is received (for example, £500 or more).
Alert a team when a high-value constituent is added.
Inform staff when a new RPI or volunteer-related activity is created.
Key behaviour
The email is sent from your configured Email Server Settings.
Recipients must be Donorfy users.
You can add {Placeholders} to the subject and body to pull in event data (for example, constituent name, amount, campaign).
Targeting with conditions
You can use a List as the condition for the trigger to control when the Email User action runs. For example:
If a constituent makes a new donation of £1,000, send a different email to users than you would for a £5 donation.
Send different internal notifications based on the location of the constituent added.
Email Constituent Action
The Email Constituent action sends an email directly to the constituent who is the subject of the trigger.
Typical use cases include:
Sending an acknowledgement email after a new transaction is added.
Sending a welcome email when a new constituent is created.
Sending follow-up messages after an RPI or activity is added.
Key behaviour
The email is sent from your configured Email Server Settings.
The recipient is the constituent associated with the trigger event.
You can use {Placeholders} to personalise the subject and body with data from the trigger (for example, amount, date, campaign, first name).
The constituent will receive the email in their inbox as a normal email, but its content will have been generated automatically when the trigger fired.
Avoid Duplicate Emails for Transactions
Each transaction in the system consists of two parts:
A Payment section.
An Allocation section.
If your List condition does not specify which type you want to trigger on, then both parts may qualify, and:
The Email Constituent (or Email User) action may send two emails per transaction.
To avoid this add a filter to your List condition such as:
Type = Payment.
Type = Allocation.
This ensures the trigger fires once per transaction, in the way you intend.
Respecting Purposes and Channels
Trigger emails themselves do not automatically check communication Purposes and Channels.
If you need to respect a constituent’s communication preferences add appropriate filters in your List condition, for example:
Only include constituents who have allowed email for a given Purpose.
Exclude constituents who have blocked specific channels.
By handling Purposes and Channels in your List filters, you can ensure trigger emails are only sent where you have the correct consent and channel permissions.