Move larger sends off the request
When an operation notifies a larger group, Wildo queues the per-recipient emails instead of sending them all on the request path. Each message keeps its own language, context and submission result.
Example — Notify a larger customer team
A team-wide update creates queued messages for its recipients, while the batch worker submits them and records their individual outcomes.
For engineers
Declare the recipients normally
Use the same resource-operation email declaration for a small or large group. The dispatcher chooses the queue when its resolved user list exceeds EMAIL_BATCH_THRESHOLD; the current threshold is ten, an internal implementation choice rather than an application setting.
Selected from notifications-dispatcher.backend.service.ts; surrounding module configuration is omitted.
const { templateRef, locale, baseContext } = await this.buildEmailNotificationContext(
executionContext,
functionParameters,
notification,
);
if (userIds.length > EMAIL_BATCH_THRESHOLD) {
await this.enqueueEmailBatch(
templateRef,
locale,
userIds,
baseContext,
notification,
emailSubmissionSourceId,
);
return [];
}
Before enqueueing, it constructs per-recipient items with locale, context and stable submission identities. The registered email.batch-send custom batch executes through the application’s batch infrastructure and calls the same EmailBackendService.send pipeline as direct delivery. Keep the worker and queue infrastructure available in the deployment.
Follow individual outcomes
The batch result includes each recipient’s outcome, provider message IDs, retryability and attempt count. Retries preserve the stored submission identity and occur only when the result permits another attempt. Queueing is not proof that every provider accepted a message, and the operation’s immediate response does not contain the later batch results.
This fan-out handles operation emails. It does not add audience segmentation, scheduling or a marketing campaign lifecycle.