Furries PH Docs
Dashboard
Event Management docs

Foundations

Event Accountability

Why event operations require careful records, clear decisions, and review before changes go live.

AudienceAll event operators, Partner admins
Dashboard surfaces/rego/events/manage?id=:eventId
Records touchedEvents, Registrations, Payments, Communications

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 Accountability narrows that work to why event operations require careful records, clear decisions, and review before changes go live. 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 All event operators 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?id=:eventId.
  • Records or contracts involved: Events, Registrations, Payments, and Communications.
  • 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 Accountability.
  2. Connect the idea to one real screen or source: Use /rego/events/manage?id=:eventId 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 Events, Registrations, Payments, and Communications 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?id=:eventId 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 Events, Registrations, Payments, Communications, 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.

Why accountability matters

Event records become promises to attendees and staff. A price, deadline, inclusion, communication, check-in rule, or refund decision can affect money, travel, safety, and trust.

Good accountability looks like this

  • Changes are reviewed before publishing.
  • Prices and inclusions match public copy.
  • Conditions of Entry are clear before attendees register.
  • Payment instructions match the actual payment process.
  • Refund and transfer decisions leave an audit trail.
  • Communications are previewed and sent to the correct audience.
  • Offline snapshots are treated as sensitive data.
  • Staff roster changes are visible to the right people.

Bad accountability looks like this

  • “We changed the price but forgot to tell people.”
  • “The email went to everyone by accident.”
  • “We approved dealers differently depending on who asked.”
  • “The refund was handled in chat but not recorded.”
  • “The check-in list was exported and shared casually.”

Accountability question

Before making a change, ask: “If an attendee, event lead, finance reviewer, or future staff member asks why this happened, can the dashboard record explain it?”

All docs