Registration to attendance: confirmation, reminders, and a follow up split on who turned up

Outcome. Someone registers and gets a confirmation in seconds, a reminder seven days out, a practical reminder the day before, and then a follow up that depends on whether they actually walked in, with the no shows kept separate from the attendees instead of both getting the same thank you email.

Workflow map Enrollment, branches and actions at a glance events-001

flowchart TD
    A[Registered for this edition] --> B[Attended = unknown]
    B --> C{First event date blank?}
    C -->|yes| D[First event date = edition start]
    C -->|no| E[Send confirmation]
    D --> E
    E --> F[Delay until 7 days before]
    F --> G{Cancelled or transferred?}
    G -->|yes| H[End]
    G -->|no| I[Send reminder at 7 days]
    I --> J[Delay until 1 day before]
    J --> K{Ticket type?}
    K -->|speaker or sponsor pass| L[Send crew reminder]
    K -->|other| M[Send attendee reminder]
    L --> N[Wait until Attended is set, 7 day expiry]
    M --> N
    N --> O{Attended?}
    O -->|attended or partial| P[Count plus 1, thank you with recordings, attendee list]
    O -->|no show| Q[Recording email, no show list]
    O -->|still unknown| R[Alert registration owner, import task]

When to use it, when not to

• UseUse it when registration and attendance are two different numbers you care about, which is every paid event, every physical event, and every webinar where the recording matters.
• UseUse it when you run more than one edition or more than one event a year, since the delays run off a date property rather than off dates typed into the workflow.
• SkipDo not use it as the ticketing system. It reads registration, it does not sell a place, allocate a seat or take payment.
• SkipDo not use it when nobody will import the badge scan file. Without an attendance source every contact stays at not yet known, the final branch never fires, and you have built three emails and a dead end.