Email Sending - Article

What Email Sending controls

Eurekos can communicate when defined platform events occur—for example, when an account is created, enrollment is confirmed, a request is approved, an Event changes, a certificate is issued, or a participant must complete another action.

Email Sending controls the reusable platform configuration behind those messages. It does not determine every trigger or recipient itself.

A complete investigation may therefore involve both Eurekos and the organization’s email provider.

Understand the Email Sending areas

Open Settings → Email Sending.

The available areas have different responsibilities:

Access to these areas follows access to Settings.

Configure System Emails

The System emails tab contains the predefined email types used by enabled platform features.

Categories can include areas such as:

• Account
• Activities
• Activity promotion
• Announcements
• Automation
• Certificates
• Commerce
• Communities
• Events
• Feedback
• Organizations
• Privacy
• Questionnaires
• Reports
• Subscriptions

The available categories and email types depend on the platform’s enabled functionality.

Find the correct email type

Choose the feature category and select the relevant email type.

A business process can use several related templates because different people receive different information. For example, an enrollment process may have separate messages for:

• The participant
• An administrator or approver
• An instructor
• A manager
• Another responsible role

Read the complete email-type name before editing. A participant-facing and administrator-facing template may describe the same event but require different instructions.

Changing a System Email does not change when its underlying event occurs or who the platform selects as its recipient.

Configure the message

Keep transactional messages concise. Put the principal action before explanatory background.

Use the editor

Depending on the current editor configuration, the body can support:

• Paragraphs, headings, emphasis, and lists
• Links to approved URLs or files
• Buttons linked to URLs, files, email actions, tokens, or questionnaires
• Images inserted through supported sources
• Alternative text and linked images
• Dynamic tokens
• Undo and redo

Use buttons for a clear action such as:

• Open the Training Activity
• Continue enrollment
• Complete a questionnaire
• Confirm participation
• View a certificate
• Open the participant’s profile or overview

Do not turn operational emails into newsletters. One obvious primary action is normally more effective than several competing calls to action.

Use tokens safely

Tokens insert contextual data when the message is generated. Available tokens differ between email types because each event has access to different underlying information.

Examples can include:

• Participant name
• Activity title
• Module title
• Start or end date
• Deadline
• Instructor
• Location
• Certificate information
• Organization information
• Signup-specific data

Use the editor’s available token list as the authoritative source for the selected email type.

Do not:

• Alter token syntax
• Translate the token itself
• Insert a token that is unsupported for the selected email
• Assume that an optional underlying field always contains a value
• Copy a token from another template without confirming that it is available

Test messages with representative data. A technically valid token can still produce an empty value if the corresponding activity, module, user, organization, or signup field is empty.

Govern notification schemes

Notification schemes let the platform distinguish between different communication preferences.

Typical schemes include:

• All emails
• Important
• No emails

The scheme names do not independently determine what is sent. Each System Email is mapped to the schemes under which it is permitted.

A user assigned Important receives email types mapped to Important. A user assigned No emails can still receive email types that are deliberately mapped to that scheme, such as essential account or security communication.

If every notification-scheme mapping is removed from a System Email, that email is not sent.

Treat the mapping as a governance decision:

• Map essential operational communication broadly enough to support the process.
• Do not classify promotional or low-value messages as essential.
• Avoid placing so many messages in Important that users lose trust in the distinction.
• Review related templates together so one business event does not produce unnecessary repetition.
• Confirm whether a separate Automated Email Workflow, Event reminder, or manual communication already covers the same purpose.

Maintain language versions

Select the relevant language from the language control before editing.

The recipient’s language preference determines which version the platform attempts to use. Confirm the expected behavior when the preferred language has no maintained translation.

For every active language, verify:

• Subject
• Body
• Buttons and links
• Token placement
• Date and time wording
• Formality and audience terminology
• Legal or policy wording
• Sender identity
• Notification-scheme mapping

Translation is contextual rather than mechanical. A technically correct translation can still provide the wrong action, describe an unavailable feature, or use terminology that differs from the participant interface.

Import and export System Emails

Import and export are useful when many templates or languages must be reviewed together.

Supported formats include:

Export email templates

1. Open Settings → Email Sending → System emails.
2. Select Export.
3. Select the required language or languages.
4. Select the applicable export type, such as all, translated, or untranslated items.
5. Select PO or XLSX.
6. Download and store the export securely.

Keep an untouched export as a backup before making a large change.

Prepare an import

Before importing:

• Preserve all system identifiers.
• Preserve tokens exactly.
• Do not translate token syntax.
• Preserve supported formatting.
• Confirm that every row still belongs to the correct email type.
• Review links, buttons, and files.
• Validate the intended language.
• Check that the file does not contain unapproved personal or confidential data.

Choose the import behavior

The import can support different update modes:

• Replace matching existing emails and add new items from the file.
• Keep existing emails and add only new items.

Select the mode deliberately. Replacing existing items can update many live templates at once.

Import email templates

1. Export and preserve the current content.
2. Prepare and review the edited PO or XLSX file.
3. Open Settings → Email Sending → System emails.
4. Select Import.
5. Select the correct language.
6. Select the intended replacement behavior.
7. Upload the file.
8. Confirm the import.
9. Review representative templates in the interface.
10. Test the affected business processes.

Do not use bulk import for one small change when direct editing is safer and easier to verify.

Configure Senders

The Senders tab defines the identity and transport used to deliver System Emails.

Sender configuration affects:

• Recipient trust
• Reply handling
• Authentication
• Spam filtering
• Domain alignment
• Deliverability
• Provider limits
• Reputation and blocklisting risk

Coordinate production sender configuration with the organization’s email and security owners.

Understand sender types

A default sender is used unless a different sender is mapped to a specific System Email. The default sender cannot be deleted, but its configuration can be updated.

Choose the appropriate email delivery service

An organization’s existing Microsoft 365 environment is often the first delivery option considered. It may be suitable, but availability does not automatically make it the right service for application-generated email.

The decision should begin with the audience, expected volume, security model, and required delivery visibility.

Distinguish the available approaches

Microsoft service capabilities and limits change over time. Confirm the current Microsoft documentation and the organization’s tenant configuration before making a production decision.

Evaluate the delivery requirements

Configure a sender

Depending on the transport, available fields can include:

Sender and Reply-to addresses should represent monitored, approved identities. Do not use an address that suggests replies are handled when no one monitors it.

Passwords are not displayed after saving and may need to be supplied again when the sender is changed. Handle credentials according to the organization’s security policy.

Test the sender

Use Send test email before relying on a sender for live communication.

Confirm:

• The connection succeeds.
• The test reaches the intended mailbox.
• From and Reply-to are correct.
• Authentication aligns with the sending domain.
• The message is not rejected or quarantined.
• The provider permits the expected volume.
• The sender is appropriate for every mapped email type.

A successful test proves that the tested configuration can send a message at that moment. It does not validate every template, trigger, recipient, or future provider condition.

Choose appropriate delivery infrastructure

For production application email, use infrastructure designed for automated or transactional sending. A dedicated email delivery service normally provides stronger support for:

• Application-generated volume
• Authentication and domain verification
• Delivery monitoring
• Bounce handling
• Reputation management
• Rate limits
• Operational separation from employee mailboxes

Microsoft 365 and ordinary employee mail services are primarily designed for human communication and may introduce limits or reduced delivery visibility when used for application-generated email. If the organization must remain within the Microsoft ecosystem, evaluate an application-oriented service such as Azure Communication Services.

Configure General settings

The General tab controls the default notification scheme, the platform’s 24-hour sending limit, and current Email usage.

Default notification scheme

Default scheme defines the notification scheme assigned when new users are created.

Select the scheme that represents the organization’s normal communication policy. Users may later be able to change their preference, but the default influences their experience from account creation onward.

Review the default scheme together with System Email mappings. A sensible default cannot compensate for incorrect mapping, and correct mapping cannot compensate for an inappropriate user default.

Sending limit

Sending limit defines the maximum number of emails that Eurekos may send during a 24-hour period.

A value of 0 disables the platform limit.

When a configured limit is reached:

• Additional emails are not sent.
• The platform does not retry those blocked messages automatically.
• Increasing the limit later does not guarantee that the missed business event will create the email again.

Determine whether affected recipients require a new valid trigger, controlled resend, or approved manual communication.

Estimate maximum volume across:

• System Emails
• Automated Email Workflows
• Calendar communication
• Event reminders
• Assignment communication
• Feedback requests
• Certificate messages
• Enrollment and approval messages
• Onboarding and import operations
• Other enabled automation

The platform limit should also remain compatible with the email provider’s limits.

Choose an appropriate 24-hour sending limit

The sending limit should protect the platform from accidental or unexpected volume without interrupting legitimate communication.

Do not base it only on the number of participants in one Training Activity. One participant can receive several messages from different platform processes during the same period.

Include potential volume from:

• Account creation and password communication
• Enrollment, cancellation, approval, and waiting-list messages
• Automated Email Workflows
• Event invitations and updates
• Mandatory-training reminders and escalations
• Assignment and questionnaire communication
• Training Feedback
• Certificate and re-certification messages
• Onboarding Rules
• Imports, integrations, and API-driven operations
• Administrator, instructor, and manager copies

Use observed and planned demand

A practical process is:

A useful planning model is:

Expected 24-hour volume = ordinary platform traffic + planned campaign communication + related reminders and copies + controlled buffer

Example

An administrator plans to enroll 2,000 participants.

The operation may generate:

• 2,000 enrollment confirmations
• 2,000 welcome workflow emails
• 500 manager or administrator notifications
• 1,200 unrelated reminders already scheduled
• Approximately 600 ordinary account, Event, feedback, and certificate emails

The expected volume is therefore approximately 6,300 emails—not 2,000. The configured limit must also remain within the approved capacity of the email provider.

Avoid these approaches

When 0 may be appropriate

A value of 0 disables the platform sending limit.

Use it only when the organization has deliberately accepted that model and has equivalent safeguards through its delivery provider, monitoring, operational approval, and incident-response process. It should not be used merely because the expected volume is unknown.

Before a high-volume operation

1. Estimate the complete 24-hour email journey.
2. Review existing Email usage.
3. Check every System Email and Automated Email Workflow that the operation may trigger.
4. Confirm provider capacity and sender status.
5. Test with a controlled audience.
6. Set or approve the required limit before the operation begins.
7. Monitor Email usage during the rollout.
8. Review Sent emails, Error log, and Retry queue afterward.

If usage approaches the limit unexpectedly, investigate the source before increasing it. Rapid growth can represent legitimate demand, but it can also reveal duplicated workflows, repeated imports, incorrect triggers, or another configuration problem.

Email usage

Email usage summarizes the latest 24-hour period:

• Emails sent
• Remaining sends
• Sending quota used

Use it before and during high-volume operations such as:

• Large user imports
• Academy launches
• Mandatory-training campaigns
• Certificate releases
• Mass enrollment
• Automated onboarding
• New communication workflows

Email usage is a platform safeguard, not a complete provider-delivery report.

Monitor email delivery

Email monitoring is separated into Sent emails, Error log, and Retry queue. Each answers a different question.

Sent emails

Sent emails provides the operational record of processed System Emails.

You can search using:

• Subject
• Message content
• Recipient email address
• Recipient name

You can also filter by:

• One or more email types
• Start date and time
• End date and time

The table can include:

• Date
• Recipient
• Type
• Subject
• Status

Where the record remains available, select the subject to review the recipient, subject, date, and generated message content.

Treat email content and recipient information as operational data. Limit access and sharing according to the organization’s privacy and support processes.

Understand the status

A Sent status confirms that Eurekos processed the message for delivery. It does not prove that the external provider delivered it to the inbox or that the recipient read it.

If the status is Sent but the recipient cannot find the email, continue with:

• Stored recipient-address validation
• Junk or spam folders
• Quarantine
• Organizational mail rules
• Provider records
• Bounce information
• Domain authentication
• Recipient mailbox status

A Not Sent status means that the platform did not complete the sending process. Continue with Error log.

Error log

Error log records sending-related failures.

The table provides the error record, message, and date. Search for the relevant sending event and compare its time with the corresponding Not Sent record.

An error can indicate problems such as:

• Sender authentication
• Unverified or unauthorized sender identity
• Provider rejection
• Invalid or unavailable recipient information
• SMTP connectivity
• Delivery configuration

Error messages can contain technical implementation information. In administrator-facing documentation and support communication, describe the business event, visible failure, date, recipient context, and relevant provider message. Do not reproduce internal module, queue, or backend identifiers.

Correct the underlying problem before resending. Repeatedly retrying an unresolved failure can create unnecessary provider traffic and duplicate operational work.

Retry queue

Emails that failed during sending can appear in Retry queue.

The queue can show:

• Date
• Recipient
• Email type
• Subject
• Available resend action

When the email record remains available, select its subject to review it.

An authorized administrator can resend:

• One eligible email
• A controlled selection
• All selected eligible emails

A confirmation is shown before bulk resend. Successfully resent emails are removed from the queue.

Older or unavailable records may no longer provide a subject preview or resend action. In that situation, determine whether the business event can safely be triggered again or whether an approved manual message is required.

Resend safely

Before using Re-send:

1. Identify why the original attempt failed.
2. Correct the sender, credential, provider, recipient, or configuration problem.
3. Confirm that the participant has not already received the message through another route.
4. Review Sent emails for a later successful attempt.
5. Select only the affected records.
6. Confirm that the content and links are still valid.
7. Resend.
8. Verify the result in Sent emails.
9. Confirm external delivery where necessary.

Do not resend an outdated approval, cancellation, deadline, password, certificate, or participation message without checking whether its underlying state has changed.

Troubleshoot a missing email

Use the following sequence:

1. Confirm the business event.
   Verify that the enrollment, completion, approval, certificate, deadline, or other event actually occurred.
2. Confirm the correct System Email.
   Check that the template exists, has an appropriate sender, contains the correct language version, and remains mapped to the recipient’s notification scheme.
3. Check feature-specific evidence.
   For an Automated Email Workflow, inspect its Notification timeline. For another feature, review its applicable status, history, or participant record.
4. Search Sent emails.
   Search using the recipient, email type, subject, content, or relevant date.
5. Interpret the status.
   If Sent, continue with external delivery investigation. If Not Sent, open Error log.
6. Correct the cause.
   Resolve sender, authentication, provider, recipient, quota, template, or process configuration.
7. Review Retry queue.
   Resend only when the message is still appropriate and the failure has been corrected.
8. Verify the final outcome.
   Confirm the new status and, when required, external delivery.

This distinguishes four separate questions:

• Was the business event triggered?
• Did Eurekos create the email?
• Did Eurekos send it successfully?
• Did the external mail environment deliver it to the recipient?

Troubleshooting

Change live email configuration safely

System Email templates and sender mappings can be reused across the platform. A small edit can therefore affect several activities, organizations, and future recipients.

Before changing live configuration:

1. Identify the affected email type, recipients, features, and language versions.
2. Review related Automated Email Workflows and feature-specific reminders.
3. Export and preserve the current templates.
4. Confirm who owns wording, translation, sender identity, and legal approval.
5. Make the smallest necessary change.
6. Test tokens, links, buttons, files, images, and Reply-to behavior.
7. Trigger a representative business event.
8. Review Sent emails.
9. Review Error log and Retry queue if the test fails.
10. Monitor the first real production use.

Do not assume that editing a template updates emails that were already generated or sent.

Design and governance practices

Realistic use cases

Email Sending checklist

Before configuration, confirm:

• The business event and intended recipient are understood.
• The correct System Email type has been identified.
• System Email and Automated Email Workflow responsibilities are not confused.
• Template, translation, sender, and delivery owners are known.
• Sensitive information is limited to what the recipient needs.
• The selected delivery provider supports the required volume and authentication.

While configuring, confirm:

• Sender and Reply-to are correct.
• The sender passes a test.
• Notification-scheme mappings match the communication policy.
• Subject and body explain the event and required action.
• Tokens are supported and unchanged.
• Every active language is reviewed.
• Links, buttons, files, questionnaires, and images work.
• The default user scheme is appropriate.
• Sending limit and provider capacity are aligned.

Before rollout, confirm:

• Current templates have been exported as a backup.
• Representative user, language, organization, and activity data have been tested.
• Critical account, enrollment, Event, feedback, certificate, and security journeys work.
• Sent emails records the expected recipient, type, subject, and status.
• Error handling and Retry queue ownership are understood.
• The first production operation has a monitoring owner.

During operation, confirm:

• Email usage remains within the intended range.
• Not Sent records and errors are reviewed.
• Retry queue is handled only after failures are corrected.
• Sent records are not mistaken for guaranteed inbox delivery.
• Duplicate communication is investigated across every sending mechanism.
• Provider rejections, bounces, and reputation are monitored externally.
• Live template and sender changes follow a controlled process.