Automated Email Workflows - Article

What an Automated Email Workflow is

An Automated Email Workflow is a reusable collection of communication rules for Training Activities. Each rule combines three decisions:

1. Who should receive the communication.
2. When it should be triggered.
3. What the subject and message should say.

For example:

• Send registered participants practical information seven days before the activity starts.
• Remind only participants who have not completed the training two days before their deadline.
• Ask only participants who have not submitted feedback to evaluate the activity one day after it ends.
• Alert an Immediate Manager when a participant has missed a mandatory deadline.
• Remind the responsible Course Administrator to confirm catering three days before an Event.
• Tell a participant that an enrollment request has been approved or declined.

A workflow can contain as many rules as the process requires. The rules do not form a required sequence in which one email waits for the previous email. Each rule is evaluated from its own audience, trigger, timing, and connected activity or module context.

Automation cannot create missing business events

A rule can react only to information that exists. A “two days before Start date” rule needs a usable Start date. “Participants missed deadline” needs a Mandatory deadline. “Participants not sent feedback” needs connected Training Feedback. A rule without its required context is skipped; creating the rule does not create the missing schedule, deadline, completion, feedback, responsible person, or manager relationship.

Automated workflows are particularly valuable when the same communication pattern is used for many deliveries, cohorts, customers, or recurring activities. They reduce manual work, but their main benefit is consistency: the same audience receives the same operational information at a predictable point in the learning journey.

Understand the four layers

It helps to treat email automation as four connected layers.

Changing one layer can affect the layers below it. For example, changing a shared workflow rule can re-evaluate enrollments in every connected activity. Changing an activity's Start date can change the effective timing of rules relative to that date. Replacing the responsible Course Administrator changes who receives the related reminders and transfers the administrator's open tasks.

Choose the correct communication mechanism

Eurekos sends several kinds of operational communication. Use the tool that owns the trigger you need.

Do not rebuild essential transactional communication unnecessarily. For example, participation approval already has System Emails for request received, administrator approval tasks, approval, decline, confirmation, and waiting-list outcomes. Use an Automated Email Workflow when you need an additional rule-driven message, audience, or timing—not merely a second version of the same confirmation.

For more detail, see System Email Notification Overview, Email Sending.

Plan the workflow before creating it

Write the intended communication journey in plain language first. For every proposed rule, answer:

• What must have happened before this message is useful?
• Who needs the information or action?
• Which exact date or personal event controls the timing?
• Does that date exist at activity level, module level, or per participant?
• Which feature supplies the recipient or status?
• What should the recipient do next?
• Which dynamic values make the message accurate?
• What should happen when the required date, recipient, or status does not exist?
• Could another workflow or System Email send substantially the same message?

A simple design table prevents most configuration errors.

Create and manage a workflow

Creating an Automated Email Workflow has two stages:

1. Create the reusable workflow template.
2. Add the individual communication rules that belong to it.

Creating the workflow does not activate it. After configuring and testing its rules, connect the workflow to the relevant Training Activity or supported module.

Use the workflow list

Open Course Administration → Automated Email Workflows.

The list contains the workflow templates available to the administrator. Each entry displays:

• The workflow title
• The number of rules currently contained in the workflow

The newest workflows appear first. Use Search to find a workflow by title. Select the workflow title to open its Rules list.

Use the actions menu to:

• Edit the workflow title or description
• Clone the workflow when a separate version is required
• Delete a workflow that is no longer required

Before editing or deleting a workflow, confirm where it is connected. A workflow can be shared by several activities or modules, and changes to its rules can affect those connected uses.

Create the workflow template

1. Select Create from the workflow list.
2. Enter a Title that makes the workflow’s purpose and intended scope recognizable.
3. Add a Description explaining where the workflow should be used, its intended audience or delivery model, and any relevant ownership or governance information.
4. Select Create.

The workflow template is created and its Rules list opens. A newly created workflow does not send anything until rules have been added and the workflow has been connected to a Training Activity or supported module.

Add and manage rules

Open a workflow to see its Rules list. Each entry shows:

• The rule’s administrative title
• The audience selected under Who to notify
• A summary of when the rule is scheduled to run

Select Create to add a rule. Use Search to find an existing rule by title. Select a rule title to open it, or use its actions menu to Edit or Delete it.

A workflow can contain as many rules as the communication process requires. The rules are independent: they do not run as a required sequence in which one rule waits for another. Each rule is evaluated from its own audience, timing, and connected activity or module context.

Configure a rule

Select Create from the Rules list, or open an existing rule for editing.

Select Save when the rule is complete. Return to the Rules list and repeat the process for each additional communication required by the workflow.

The following sections explain the available Who audiences, When combinations, message design, and dynamic tokens in detail.

Reuse or clone

Reuse one workflow when the complete communication pattern, tone, and timing are genuinely shared. This is useful for a standard instructor-led delivery model or a common compliance journey.

Clone and customize when:

• A customer or audience needs different wording.
• A delivery model has different timing or responsible roles.
• A workflow is already connected to live activities and a material change should not affect them.
• A new version needs controlled testing before rollout.

Treat a reused workflow as shared configuration. Before changing it, identify the activities and modules that rely on it and consider the effect on both future and existing enrollments.

Configure Who receives the rule

The Who field defines the audience. Some audiences are direct; others depend on a participant's status, feedback, deadline, activity responsibility, organization, or profile relationship.

The approved and declined request audiences are relevant only where the participation-approval workflow is enabled. Availability can depend on platform configuration and the rule context.

Participants

Use Participants for information every registered participant needs, regardless of current completion or feedback status.

Examples:

• Preparation instructions after enrollment
• Venue or virtual-delivery information before the start
• A general follow-up after the activity ends

This broad audience can include people who have already completed or submitted feedback. Use one of the conditional participant audiences when the purpose is to prompt an outstanding action.

Participants not completed

Use Participants not completed when the message is relevant only while the connected Course, Event, or activity remains incomplete for that person.

The definition of completion depends on the learning design. Course progress, Event attendance, schedules, certificate criteria, manual completion, and completion behavior can all contribute. Attach the workflow at the same level whose completion you intend to evaluate.

Example: a module-level reminder should use the Course or Event module's workflow connection when the learner only needs to finish that module. An activity-level rule concerns completion of the complete learning path.

Participants not sent feedback

Use Participants not sent feedback for targeted Training Feedback reminders. The feedback questionnaire and workflow should be connected at the same relevant activity or supported module level.

Include the Activity leave feedback button token when the participant should go directly to the feedback action. Test the resulting button with a real enrolled participant; Participant Preview is not a complete submission test.

Submitting the same questionnaire through another distribution route, such as an anonymous URL or a Button widget in Course content, is not necessarily the same connected Training Feedback instance.

Participants missed deadline

Use Participants missed deadline for overdue mandatory training. It depends on the activity's Mandatory feature and a calculated Deadline.

The deadline can be:

• A number of days after the activity starts
• A number of days or months after the participant enrolls
• A specific date and time for all active signups

Relative-to-enrollment deadlines can differ by participant. If a deadline is updated, Eurekos recalculates it for active signups and for a signup that later returns to Registered from states such as Expired, Cancelled, Waiting list, or Reserved.

The participant-facing Overdue label is informational; the workflow rule supplies the escalation communication. Choose a trigger after Deadline when the message is intended for people who have actually missed it.

People in waiting list

Use People in waiting list for activity-capacity communication—for example, confirming that interest is recorded or explaining what to expect if a seat opens.

A Waiting list signup is not registered and does not receive access from that status. If the person is promoted to Registered, future communication should be designed around the registered-participant journey. Coordinate workflow wording with the platform's waiting-list and enrollment System Emails so the participant does not receive contradictory messages.

Course administrators and instructors

These audiences use the people assigned as responsible in the activity or module features.

• An activity-level rule uses activity-level responsibility and context.
• A module-level instructor rule should use the instructor responsible for that module.
• If nobody is assigned at the relevant level, there is no valid responsible recipient for that rule.

Course Administrator rules also support operational task reminders; these are described later in this article.

Organization Managers and Immediate manager

Manager audiences are evaluated from the participant's current organization or profile relationships. Use them for escalation, approval support, or reinforcement when the manager has a legitimate role in the process.

Before rollout, test participants who have:

• One valid manager relationship
• No manager relationship
• Recently changed organization or manager
• A manager who is blocked or otherwise unable to receive communication
• Multiple organizational relationships, if your data model permits them

Do not put sensitive participant information in a manager email unless the recipient scope and business purpose have been approved.

Email (custom)

Use Email (custom) for a fixed operational mailbox or external recipient not derived from a responsible-person or manager relationship.

The custom address is the notification recipient; it is not the participant represented by the signup. This changes which name token is appropriate:

• Signup user full name returns the participant connected to the signup.
• User full name original, User first name, and User last name describe the user selected through Who. With a custom email recipient, this can render as anonymous instead of the participant's name.

Custom-recipient rules can generate substantial volume when the rule is evaluated in many participant contexts. Use a shared mailbox with a clear operational owner, keep personal data to the minimum required, and test with more than one signup.

Approved and declined enrollment requests

Use the request-status audiences for additional participant communication after a participation request is approved or declined.

• A Pending or Potential fit request is not appropriate for either audience, so both rules are skipped.
• For an Approved request, the approved rule can be scheduled or sent; the declined rule is skipped.
• For a Declined request, the declined rule can be scheduled or sent; the approved rule is skipped.
• If a decision changes after a notification was sent, the sent email cannot be withdrawn. The opposite rule may remain not applicable rather than automatically correcting the earlier message. Use Send notification where the timeline offers it and send a clear correction if needed.
• A Questionnaire after approval or participant-confirmation process can extend the request journey. Review the final status and timeline instead of assuming the first approval action completed enrollment.

If the request-status rule is timed from a Start or End date and the activity has no usable Schedule, the notification is skipped. The timeline can offer Send notification manually when the request has the matching Approved or Declined status.

Configure When the rule runs

The When field combines a unit/direction with a reference event.

The rule is not based on the day it was created. It is calculated from the selected reference for each connected context and, where applicable, each participant.

Start date

Use Start date for preparation, joining information, manager briefings, and operational readiness.

At activity level, the rule needs a usable activity schedule. A single-module activity can derive its effective schedule from its module when the activity Schedule feature is enabled. For a multi-module activity with Schedule enabled, the effective activity period is based on the earliest module start and latest module end, within any configured activity boundaries.

At module level, use the module's own Start date. Event modules require Starts and Ends. A Course module can have an optional Schedule.

End date

Use End date for follow-up communication that should occur at the end of a scheduled delivery, such as feedback requests, next-step instructions, or administrator close-out tasks.

End date is a schedule value, not proof that a person completed the learning. Use Participant completed when the message should follow the participant's individual completion event, or use a conditional audience such as Participants not completed when status matters.

Deadline

Use Deadline for mandatory-training reminders and escalations. The selected rule timing is calculated from the signup's effective Deadline, which may be the same for everyone or participant-specific.

Examples:

• Participants not completed, 7 days before Deadline
• Participants not completed, 1 day before Deadline
• Participants missed deadline, 1 day after Deadline
• Immediate manager, 3 days after Deadline

Do not use Participants missed deadline before Deadline; the audience condition and timing would describe different states. Use Participants not completed for pre-deadline reminders.

Participant enrolled

Use Participant enrolled for onboarding and preparation relative to a person's enrollment.

Examples:

• At the time of Participant enrolled: welcome and next steps
• 2 days after Participant enrolled: prompt the participant to begin
• 14 days after Participant enrolled: progress reminder for self-paced learning

This is an individual event. It is usually more suitable than Start date for continuously available self-paced training.

Do not duplicate the platform's essential registration confirmation without a distinct purpose. The System Email communicates the transaction; the workflow can provide learning-specific guidance.

Participant completed

Use Participant completed for individualized congratulations, follow-up resources, transfer-to-work prompts, or next-step guidance.

The trigger occurs from completion at the connected level. If a participant completes a Course module before the overall learning path, a module-level completion rule and an activity-level completion rule represent different moments.

Certificate issuance and re-certification have their own system communication. Use a workflow only when the participant needs additional contextual guidance.

Hours or days

Use hours for time-sensitive operational communication, such as a virtual-session reminder. Use days for preparation, learning nudges, feedback, deadlines, and follow-up.

Avoid multiple rules that resolve to nearly the same time unless each has a distinct purpose. “24 hours before” and “1 day before” can create an unnecessary pair of reminders rather than a useful sequence.

Map every trigger to its dependency

The notification timeline is the authoritative operational view for an individual activity and signup. Use it to distinguish a rule that was logically skipped from an email that was sent but not delivered to the inbox.

Write the subject and message

The email should explain:

• Why the recipient is receiving it
• Which Training Activity or module it concerns
• The relevant date, deadline, status, or event
• What the recipient needs to do
• Where to complete the action or find more information
• Who to contact when the standard process does not apply

Keep each rule focused on one primary action. Long newsletters make operational instructions harder to find and increase maintenance when the same workflow is connected to many activities.

Use dynamic tokens for values that differ by activity, module, recipient, or participant. Avoid typing a fixed date, venue, instructor, or activity title into a reusable workflow unless the workflow is intentionally dedicated to one delivery.

Use dynamic tokens correctly

Tokens insert current contextual information into the subject or body. The available token list includes the following groups.

Activity tokens

Module tokens

Choose between Activity location and Module location

Use Activity location when the message concerns the complete Training Activity:

• One distinct module Location produces that Location.
• Two or more distinct module Locations produce Multi-site.
• Modules without a Location do not affect the value.

An Activity location value of Multi-site is useful as a general description, but it does not provide the venue for a particular session.

Use a module-level workflow with Module location when participants need a specific address, room, or venue link. This is particularly important in learning paths containing several in-person sessions at different Locations.

User and signup tokens

Use Signup user full name when an email to a manager, administrator, instructor, or custom address must identify the participant concerned. Use the ordinary User tokens when the message should greet or identify the actual user selected as the recipient.

Alert title

Alert title supports the Course Administrator reminder/task function. Use a short, action-oriented title such as “Confirm room setup” or “Send material to instructor.” It is not a replacement for a meaningful participant email subject.

Token safety

Before rollout:

1. Insert tokens from the editor rather than typing or altering their underlying syntax.
2. Match activity tokens to activity connections and module tokens to module connections.
3. Confirm that the source field—Schedule, Location, Responsible, Deadline, Certificate, or Questionnaire—contains a value.
4. Test different recipient types, especially custom emails and managers.
5. Check date, time, time-zone, and language presentation in the delivered message.
6. Test action tokens such as feedback and certificate actions with an eligible participant.

A token cannot display data that is absent from the connected context. If a module has no Location, inserting Module location does not create one.

Connect the workflow to a Training Activity

Creating a workflow does not activate it. Connect it through the Training Activity's Automated email workflow feature.

Activity-level connection

Use activity level when the rule concerns the complete Training Activity or learning path.

1. Open Course Administration → Activities.
2. Edit the Training Activity.
3. Open activity-level Features.
4. Enable Automated email workflow.
5. Select the workflow.
6. Save the activity.

Good activity-level examples include:

• Overall learning-path preparation
• A reminder based on the full program's Start or End date
• Completion or feedback for the complete learning path
• Mandatory deadlines set on the activity
• Responsible Course Administrator tasks for the overall delivery

Module-level connection

Use module level when the rule concerns a particular supported Course or Event module.

1. Edit the Training Activity.
2. Open the Course or Event module's Gear or Features menu.
3. Enable Automated email workflow.
4. Select the workflow.
5. Save the module and activity.

Good module-level examples include:

• Joining instructions for one Event in a learning path
• A reminder based on one Course module's Schedule
• Instructor or Location information that differs by module
• Completion follow-up for one module rather than the full learning path
• Module-specific Training Feedback

An Assignment has its own due-date reminder behavior. Existing Training connects an independent child activity with its own configuration. Use the workflow at the level that owns the relevant schedule, completion, feedback, and participants.

Single-module activity

For one Course or Event module, module-level configuration usually provides the clearest context. If an activity-level rule uses the activity schedule, ensure the activity Schedule feature is enabled and resolves the module's dates as intended.

Learning path

A learning path can use:

• One activity-level workflow for the overall journey
• Different module-level workflows for individual Courses or Events
• Both activity- and module-level workflows
• Multiple workflows where the feature and design permit them

This flexibility also creates overlap risk. Before saving, compare all connected rules by audience, trigger, and message. The platform cannot decide that two differently configured reminders are semantically duplicates.

Understand schedule and time-zone context

Schedule-based rules use the dates and time zones configured at the connected level.

• Activity and module schedules each have their own time-zone field.
• Event Starts and Ends are required.
• Course module Schedule is optional.
• Activity Starts and Ends can be optional.
• If activity-level Schedule is disabled, the activity is treated as self-paced even when modules have dates.
• In a single-module activity with activity Schedule enabled but blank, the effective activity schedule can be based on the module.
• In a multi-module activity with activity Schedule enabled, the effective period can use the earliest module start and latest module end, subject to activity/module schedule validation.

When a workflow is attached at activity level, use activity date tokens and verify the effective activity period. When it is attached to one Event, use module date tokens and the Event's time zone.

If participants, instructors, and administrators work across time zones, test the delivered value with accounts using representative regional settings. The rule timing and the date displayed in the message must both make sense to the recipient.

For more detail, see Calendar Events and Video Conferencing, Creating a Training Activity.

Change a workflow used by live activities

Workflow rule updates apply to existing enrollments going forward. This includes adding a new email rule and changing the trigger on an existing rule.

When the workflow is saved, Eurekos re-evaluates existing enrollments:

This prevents a workflow edit from generating a large wave of old reminders while still including existing participants in future communication.

Examples

Add a seven-day pre-start reminder 20 days before the activity starts: existing registered participants are included because the trigger remains in the future.

Add an “at enrollment” welcome rule after participants enrolled last week: the historical enrollment trigger is too old and is skipped. Use a manual message for the current cohort.

Save a rule a few minutes after its calculated trigger: the grace window can send it immediately. This is useful operationally, but it also means saving near a live trigger can produce immediate emails.

Safe live-change process

1. Identify every activity and module using the workflow.
2. Calculate each changed rule's effective time for current enrollments.
3. Check for a trigger within the short grace window.
4. Review the size and sensitivity of the affected audience.
5. Clone the workflow first if the change should apply only to new activities.
6. Save during a controlled period.
7. Review notification timelines and email logs after the change.
8. Use a manual message for historical cases the automated rule correctly skipped.

Changing the wording of a shared workflow should receive the same governance review even when timing is unchanged. Future messages across every connected use may inherit that wording.

Monitor the notification timeline

Open the Training Activity's participant administration and use the Notification timeline for the relevant signup or request. It brings together the statements created from the connected workflow rules.

Typical outcomes include:

• Notification scheduled: the rule is applicable and its send time is in the future.
• Notification sent: the rule was processed and the message was sent from Eurekos.
• Notification skipped: the rule was not applicable or required context was missing. The reason can identify an inappropriate request status or missing Start/End date feature.
• Rule is not applicable: the participant or request no longer matches the rule's state.
• Send notification: a manual option is available for a valid edge case.

The notification timeline answers “Did this rule execute for this signup?” It does not prove that an external mailbox placed the email in the inbox. If the timeline says Sent but the recipient did not receive it, continue with Settings → Email Sending → Logs, recipient-address validation, sending limits, sender configuration, spam filtering, and delivery-provider investigation.

Enrollment-request timeline behavior

For approval/decline rules, the timeline reflects both the request status and the rule audience.

This audit trail is important when a participant reports conflicting communication. Review the sequence of request status changes as well as the email timeline.

Create Course Administrator reminders and tasks

When Who is Course administrators, the rule supports an additional reminder/task field represented by Alert title.

This function applies specifically to the system role Course Administrator.

Requirements:

• A responsible Course Administrator must be assigned to the Training Activity.
• The workflow must be connected at the appropriate level.
• The rule needs a valid trigger, such as a Schedule date.
• The task title should describe one concrete action.

The reminder appears on the Course Administrator's Home screen above the calendar. It remains associated with the Training Activity and can be marked complete or incomplete.

Examples:

• Confirm the instructor and venue
• Order catering
• Send pre-reading material
• Check minimum attendance
• Export nameplates
• Record attendance
• Review feedback and close the delivery

If the responsible Course Administrator is replaced on the activity, the related tasks are transferred automatically to the replacement.

An email reminder and a dashboard task should not be treated as proof that the underlying operational action was completed. The Course Administrator must mark the task complete after performing it.

Common use cases

Design and governance practices

Verify the configuration

Use representative accounts and the routes enabled for your delivery. Check the relevant outcomes before launch and after a material change; an administrator preview alone does not verify the participant experience.

Troubleshooting