Sent messages — admin

Communications → Sent messages. The same list is on every person's page and every registration's page, under "Messages", because that is where the question is usually asked.

Who opens it: whoever answers "she says she never got her ticket" — an organizer, the registration team, a group lead for their own people. What they came to do: find the message, see what became of it, and, where it failed, read why. What must be true when they leave: they know whether it was sent, whether it arrived, and if it did not, what the mail or text provider said — in the provider's words — and they have put it right or know who can.

What a row is

One attempt to reach one person: who it was for and the address or number on their contact now, which event, which template (and whether it was sent by hand or resent), the channel, where it got to, and when it was sent — in the event's own time, or your organization's where an event has none.

Search by name, email address or phone number; filter by status, channel and event.

The delivery timeline

Open a row for its timeline: queued, sent, delivered, opened where that is known, bounced or complained, each with its moment. A failure is shown in the provider's own words — "The server was unable to deliver your message (ex: unknown user, mailbox not found)" — and never paraphrased, because the paraphrase is where the useful part gets lost.

Nothing extra is stored to draw it. Every change to a message is already in the audit log; the timeline is that history read back for one message. Where the audit rows have aged out under your plan's retention, the timeline shows what the message itself still knows: when it was queued, when it was sent, and where it ended up.

From a person or a registration

A person's page and a registration's page each carry a Messages list with the same columns, so a bounced ticket email is found from the page you were already on: open the person, look at Messages, read the reason under "Bounced".

Who sees what

communications.read. A member limited to one group sees messages about the people in their group and below it, the same rule the API's GET /messages applies. The log is read-only: nothing here edits a message. A resend writes a new one, and needs communications.send.

Resending

Resend, on an open message, sends the same template to the same person again — to the address on their contact now, or to the one you type instead.

• It is a new message. The original keeps its history, bounce and all; the new one says "Resent by hand" and each links to the other. Nothing already sent is ever edited.
• Correcting the address corrects the contact, so the next scheduled message goes to the right place as well. If the old address had bounced, that goes with it: the bounce was a fact about the old address, and the audit log says the address was corrected. An address another contact already has is refused rather than merged.
• A bounced address you have not corrected is refused until the bounce is cleared — resending to an address that does not exist only bounces again, and costs your sending reputation each time.
• Somebody who marked a message as spam is never resent to, corrected address or not. The button says why.
• One at a time. While a resend of a message is still waiting to go, a second press is refused, so a double click sends once.
• A text goes to the mobile number on the contact, unless they replied STOP. A printed sheet is not resent.