Mass Email to the Community

This is the "send" half of running a community event. In Council Meetings & Notifications you built the audience; here you email them all at once. This article shows you how to launch the Mass Email wizard from a council event, where the sender and template come from (your administrator sets them, not you), how to run a safe test send first, and — most importantly — the two behaviors that catch people out: a notification that quietly borrows a meeting's audience, and a post-send cleanup that can delete a notification's recipient list. Read those two before your first big send.

What Mass Email does

Mass Email sends one email to every participant of a council event, and logs each send on the event so you have an auditable record of who was contacted. It runs per event, not per roster — the recipient list is the event's generated participants (from Council Meetings & Notifications), not a roster you pick at send time.

Three audiences, one sender

By now you've met a few different "who gets this" ideas, so let's line them up:

• Event participants are the recipient list this wizard uses. The send targets the event's participants — nothing else.
• The roster-level General Notification flag (from Councils & HOA Rosters) marks who belongs in community mailings — it shapes who you generate as participants, but the wizard itself reads the participants, not the flag.
• A Meeting send doubles as the invitation mechanism — it stamps the invitation timestamp that unblocks the Invitation Sent status. A Notification send is a plain blast, optionally archived afterward.

Before you send: the configuration card

When the wizard opens, it shows a configuration card with the sender address and the email template already filled in. You can't change these in the wizard — your administrator configures the sender, template, and archiving behavior for each type of send. If the sender or template looks wrong, that's an administrator conversation, not something you fix mid-send.

Who receives it

The wizard resolves the audience like this:

• For a Notification that has a Parent Council Meeting set, it uses the meeting's participants — you don't regenerate a list on the notification.
• Otherwise, it uses the event's own generated participants.

It then counts the participants who have an email address and shows that number. Participants without an email are simply not counted — they're skipped, not blocked. If the count comes to zero, the wizard stops at an error screen and nothing is sent; go back and generate participants, or fix the missing contact emails.

Sending, step by step

Where did my participants go?

This is the behavior that surprises people, so it gets its own section. When your administrator's configuration has archiving switched on and the event is a Notification (not a meeting), REDA deletes all of that notification's participants after the send — a privacy-archiving step. The emails stay logged on the record; the recipient list is gone.

What's kept after a send

Because every send writes one log per recipient, the event's email history is your audit trail — check it before re-blasting, since sending again creates a fresh set of logs and there's no built-in guard against sending twice.

Worked example: emailing the AGM

Continuing the Harbour Tower Owners Association AGM from Council Meetings & Notifications: the manager opens the AGM meeting and clicks Mass Email. The configuration card shows the community's sender address and the AGM invitation template, both set by the administrator. Of the 17 participants, 16 have email addresses, so the count reads 16. She sends a test to herself, it looks right, she ticks consent, and sends. Result: 16 logged sends, and the Invitation Sent Date Time is stamped on the event and every participant — so she moves the meeting's Status to Invitation Sent without hitting the validation rule. A week later she blasts the "AGM Minutes Distribution" notification, whose Parent Council Meeting is the AGM; it reuses the same recipients. Because her organization archives notification data, the notification's participant list is deleted after the send — expected behavior, and the send log remains for the audit trail.

Where to go next

1. Council Meetings & Notifications — generate the participants this send targets, and the Invitation Sent gate.
2. Councils & HOA Rosters — the General Notification flag that marks who belongs in mailings.
3. Administration — where your administrator maintains the mass-email configuration.

Frequently asked questions