Event settings

What event settings control

Admin → Settings holds event-level configuration: naming, dates, rooms, tracks, and related program parameters. Schedule studio and public surfaces consume these values. Change them deliberately mid-season; room renames can confuse published grids.

Treat settings as the skeleton of the program. Forms, schedule, and comms all hang off a correct event identity.

Operator setup sequence

Create or select the event. Set display name and schedule bounds. Add rooms with capacities if modeled. Add tracks that match the CFP. Confirm timezone expectations for schedule inputs. Save and open schedule studio to verify rooms appear.

1. Open Admin → Settings for the active event.
2. Verify event name, slug, and date range.
3. Create rooms you will place sessions into.
4. Create tracks that match form and program taxonomy.
5. Save and spot-check schedule and public references.
6. Document the public event name for comms templates.

Rooms and tracks in depth

Rooms need stable identifiers because schedule placements reference them. Tracks should match CFP options so accepted talks route cleanly into the grid. Avoid renumbering rooms after the public grid ships; prefer display label updates when the product supports them.

• Room list complete before schedule place marathon
• Track names match CFP select options
• Timezone agreed with ops and printed materials
• Slug stable once public CFP is marketed

CLI helpers

Read-only listing of rooms and tracks supports agents assembling schedule plans.

speakerops rooms list --event <eventId> --json
speakerops tracks list --event <eventId> --json
speakerops events get --event <eventId> --json
speakerops events list --json

Guardrails

Only admins should change event settings. Export or screenshot configuration before large renames. Keep production secrets out of event description fields. After changing dates, re-check task due offsets and comms copy that mention days of week.