Event Records and Public Pages

Start With The Idea

Use this guide when event setup, attendee operations, staff work, payment-adjacent tasks, public pages, or closeout records need a controlled path. In this guide, Event Records and Public Pages narrows that work to how dashboard event records drive public registration pages and attendee-facing information. Because this is a foundations page, read it as part of the Event Management learning path rather than as an isolated checklist.

Event records become real-world instructions: what attendees see, what staff do, what money or inventory must reconcile, and what future organizers inherit. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What This Page Explains

This is the concept layer. Read it before trying to operate the workflow so the later steps make sense in ordinary language first. The intended readers are Event leads and Partner admins. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /rego/events/manage/details?id=:eventId and /events/:slug.
• Records or contracts involved: Event records, Public pages, and Registration forms.
• Main care point: Watch for changing one part of the event without checking attendees, staff, finance, communications, public information, and closeout records.
• Proof worth keeping: event ID, dashboard state, public page, attendee record, payment or refund state, check-in count, roster note, export, and reviewer signoff.

How The Idea Builds Toward Action

1. Say the idea in ordinary words: Begin by naming the Event Management situation, the owner, and the exact item involved in Event Records and Public Pages.
2. Connect the idea to one real screen or source: Use /rego/events/manage/details?id=:eventId and /events/:slug to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Name what could change for people or records: Keep Event records, Public pages, and Registration forms in view so the work stays tied to the records or contracts it can affect.
4. Choose the next practical guide from the related links: Before handing off, save proof such as event ID, dashboard state, public page, attendee record, payment or refund state, check-in count, roster note, export, and reviewer signoff so the next operator can see what changed and why it was safe to continue.

You Are Ready To Continue When

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on attendees, staff, money, public pages, communications, and post-event records.
3. Proof is findable: The handoff points to evidence that the next operator can see what changed and why it was safe to continue.

End-to-end operator runbook

Use this numbered runbook when you need to operate this area without getting stuck. Read the purpose of each step, do the action in order, and use the final sentence as the checkpoint before continuing.

1. Step 1 - Choose the right path. Read this page before operating the related dashboard workflow so the terms and risks are clear. This anchors the work to the correct scope before any record changes.
2. Step 2 - Confirm scope and records. Identify which people, records, and community outcomes the workflow can affect. Pause here and confirm the attendee, staff, money, and public-page impact still matches the event plan.
3. Step 3 - Do the operating action. Open /rego/events/manage/details?id=:eventId, /events/:slug only when you know what decision or check you are performing. This keeps the event state understandable before another setting changes.
4. Step 4 - Verify the result. Before changing Event records, Public pages, Registration forms, ask whether the action is fair, accurate, necessary, and explainable later. The next operator should be able to see why this step was taken.
5. Step 5 - Hand off remaining work. Use the related pages to move from concept to the exact operating surface, lifecycle, or reference checklist. This leaves a handoff trail another operator can understand.

Dashboard record

The event record is the source for event name, dates, venue, status, public/internal names, images, and many connected settings.

Public page

The public event page is what attendees see. It can expose:

• Event name and dates.
• Venue and public description.
• Registration availability.
• Tiers, add-ons, inclusions, and forms.
• Conditions of Entry.
• Dealers Den registration where applicable.

Dashboard-only information

Some fields are operational and should not be treated as public copy:

• Internal event name.
• Staff notes.
• Payment reconciliation state.
• Check-in state.
• Offline snapshots.
• Staff roster internals.
• Analytics and settlements.

Safe publishing checklist

Before making public registration visible:

1. Checkpoint 1. Event title, dates, venue, and description are correct. Use it to confirm the work is still on the right path.
2. Checkpoint 2. Registration tiers and prices are correct. Use it to confirm the work is still on the right path.
3. Action 3. Add-ons and inclusions match the public offer. Confirm the visible event state before continuing.
4. Checkpoint 4. Conditions of Entry are assigned. Use it to confirm the work is still on the right path.
5. Checkpoint 5. Payment instructions are tested and clear. Use it to confirm the work is still on the right path.
6. Checkpoint 6. Confirmation and notification behavior is reviewed. Use it to confirm the work is still on the right path.
7. Checkpoint 7. Staff know who monitors new registrations. Use it to confirm the work is still on the right path.