Speakers admin list

Person versus speaker

A person is a durable identity (email and name). A speaker for an event is a participation linking that person to the event. Accepting a submission creates or links participations; it does not duplicate person rows per event. Admin → Speakers lists participations for the active event with search and status context.

This model prevents the classic spreadsheet failure where the same human appears five times with slightly different emails. Prefer correcting person identity carefully over creating parallel rows.

Daily operator uses

Search for a speaker by name or email. Open participation detail to see tasks, files, and session links when present. Use the list to find people missing headshots, outstanding tasks, or schedule assignments before you send reminder comms.

1. Open Admin → Speakers for the event.
2. Use search to locate a person or scan filters if available.
3. Open a participation and review tasks and readiness-related fields.
4. Follow up via portal task nudges or comms templates as needed.
5. After portal completions, refresh readiness to confirm outstanding counts drop.

Performance expectations

Large events can list hundreds of speakers. The product is designed for paginated or bounded queries rather than dumping unbounded graphs into the browser. If the list feels slow, see the FAQ on speakers list performance and avoid client-side patterns that fetch every row repeatedly.

Bridge to portal and readiness

Outstanding speaker tasks roll into the readiness dashboard. Completing work in the portal clears items operators see on readiness. Keep task templates tight so the speakers list and readiness stay actionable instead of noisy.

• Accept → participation + tasks
• Portal complete → readiness clears
• Comms remind outstanding task owners
• Schedule uses sessions linked to speakers after program placement

Common operator mistakes

Emailing speakers from personal inboxes outside templates loses audit and personalization tokens. Editing D1 rows by hand breaks audit trails. Creating duplicate people when an accept already linked the right email creates double portal invites.