Email Sending

Access Prerequisites

• Permission (module): access granted by the route's administrative guard (admin). There is no specific dynamic module for this screen — any operator with access to the BackOffice and to the Communication group can open it.
• License/Feature: None.
• Menu location: GENERAL → Communication group (icon campaign) → Email Sending.

What it is / when to use

Screen for creating and scheduling bulk email sends (or to a specific list of recipients) from the BackOffice. Use it for announcements, promotional campaigns, operational notices and relationship messages, without needing a deploy or an external tool. Each send created becomes a "mass action" (entity MassActions, action = 'EMAIL') that enters a queue and is processed by a CommunicationGateway scheduler — there is no synchronous sending at the moment of "Confirm".

Prerequisites

• Permission: the item is under the route's admin guard. Remember that in Axia the permission is dual (CPM enum on the backend + dynamic module in the DB); here the effective gate is the route guard, so validate that the operator has an administrative profile.
• License/Feature: no license feature is required to open the screen.
• Dependencies on other screens: in single mode (individual recipient), the email entered is validated against the user database — only those with a registered account/wallet are added to the list. For the final visual content of the emails, the Template Master defines the HTML "envelope" applied to sends.

Step by step

1. Access the menu Communication → Email Sending.
2. The screen lists the sends already created, with the columns When, Subject, Status and edit/delete actions.
3. Click New / Create to open the creation modal.
4. Choose the audience in the top selector: All (all) or Individual (single).
5. In Individual mode, type each email and click the + button to validate it and add it as a chip; repeat for each recipient.
6. Fill in Subject, Message and the scheduling Date.
7. Click Confirm. The send is created with an initial status and enters the scheduler queue.

Fields

Listing

Column	What it shows	Data source
When (when)	Creation/scheduling date of the send	when/scheduleTo field of MassActions
Subject (subject)	Email subject	subject field
Status (status)	Send state: CREATED/PENDING (in queue), EXECUTED (sent), CANCELLED (cancelled)	status field, updated by the scheduler
Edit	Reopens the modal in edit mode	—
Delete	Cancels the send (does not remove: marks status = 'CANCELLED')	—

Creation/edit modal

Field	What it is	Required?	System/backend effect
Audience (All / Individual)	Defines whether the send goes to the entire base or to a list	Yes	On the backend, all = true makes the handler fetch all users (getAllUsers) and create one mass_actions_users PENDING record per user; all = false creates one record per email in the list. In edit mode, the toggle is locked (you cannot change the audience of an existing send).
Email (Individual mode only)	Recipient to be added	Conditional (≥1 in Individual mode)	When clicking +, the email is validated against the database via getUserByEmailWallet: it is only accepted if a corresponding user/wallet exists. Becomes a chip; the send cannot be confirmed with an empty list in Individual mode.
Subject (subject)	Email subject line	Yes	Saved in MassActions.subject (max. 100 characters). Used as subject in the actual send.
Message (message)	Email body	Yes	Saved in MassActions.message. Supports HTML and the personalisation token @user.name (see Rules). It is injected into both bodyData and htmlData on send.
Date (when)	Date from which the send can be processed	Yes	Minimum = today (past dates not allowed). The scheduler runs every 30 minutes and processes the queue; the date governs the scheduling of the send.

Actions and modals

• Create (Confirm): creates the MassActions (action = 'EMAIL', status = 'CREATED') and the PENDING recipient records. After saving, the screen reloads.
• Edit: allows adjusting the Subject, Message and Date of an existing send; the audience (All/Individual) and the email list are read-only. On saving, the send returns to status = 'CREATED'.
• Delete: does not physically remove — marks the send as CANCELLED, removing it from processing.
• Step-up / MFA: this screen does not trigger re-authentication by default. Treat bulk sends as a sensitive operation (wide audience, irreversible after sending).

Business rules / cautions

Attention

• An individual email is only accepted if it already exists in the database (getUserByEmailWallet validation). External/unknown addresses are not added to the list.
• Sending is not immediate: the CommunicationScheduler runs on the cron */30 * * * * (every 30 min). After "Confirm", there is latency before the send goes out.
• The message accepts HTML. Since the body is injected into bodyData and htmlData, malformed HTML can break rendering in providers such as Mailgun/Brevo/SendGrid (in SES the problem is masked).
• Personalisation: if the message contains @user.name, the scheduler fetches the user's first name and replaces the token per recipient. Without the token, the message is sent verbatim.

Irreversible

• Once the scheduler processes the send, there is no rollback for emails already sent. Deleting/cancelling only prevents sends still PENDING — emails already EXECUTED remain delivered. Review the audience, subject and body before confirming, especially in All mode (reaches the entire base).

• Idempotency: processing is idempotent per recipient — each mass_actions_users is only sent when it is PENDING and moves to EXECUTED after sending. Scheduler re-runs do not resend to those who have already received the email. At the end, MassActions also moves to EXECUTED.
• Note on state: CANCELLED sends are ignored by the scheduler.

Examples

Scenario 1 — Announcement to the entire base

1. New → audience All.
2. Subject: Scheduled maintenance over the weekend.
3. Message (simple HTML): <p>Hello @user.name, we will perform maintenance on Saturday from 2am to 5am.</p>.
4. Date: today.
5. Confirm. The handler creates a PENDING record for each user in the base; in the next scheduler cycle (≤ 30 min) each one receives the email with their first name in place of @user.name. Send status moves to EXECUTED.

Scenario 2 — Individual send to a short list

1. New → audience Individual.
2. Type joao@cliente.com, click + (validated against the database → becomes a chip). Repeat for maria@cliente.com.
3. Normal subject and message; Date: today.
4. Confirm. Only the 2 recipients receive PENDING records. If an email does not exist in the database, + does not add it and it is left out.

Scenario 3 — Correcting the subject of a send not yet sent

1. In the listing, click Edit on a CREATED/PENDING send.
2. The audience selector and the email list appear locked; adjust only Subject or Message.
3. Confirm. The send returns to CREATED and will be reprocessed by the scheduler. Recipients still PENDING receive the corrected version; those already EXECUTED are not affected.

Related screens

• SMS Sending
• Template Master
• Email Templates
• Newsletter
• Mass Action (overview)