Festivals and conferences that run parallel tracks usually end up keeping the schedule in two places — once inside the system where tickets are sold, and again inside whatever tool attendees actually browse to plan their day between stages. Every time a session moves, a teacher drops out, or a room changes, someone has to update both places by hand, and the two versions drift apart the moment someone forgets. BrightStar's Sched integration closes that gap. Once it's connected, a change you make on BrightStar reaches Sched without a second pass, so the lineup attendees are looking at on their phones matches what your team is actually running.
What information moves from BrightStar to Sched
BrightStar sends over the pieces that make a multi-track schedule usable: each session with its start and end time, which track or stage it belongs to, the presenting artists or teachers along with their bios and photos, and the venue and room. This is the information an attendee actually needs to decide what to walk to next — not just a session title, but where it is, when it starts, and who's leading it. Sending bios and photos along with the session means Sched can show attendees a real picture of who they're about to sit with, which matters at a kirtan or teaching track where the draw is often the person, not just the topic.
Setting it up
Setting it up:
- 1Open Dashboard → Integrations and choose Sched
- 2Authorise with your Sched account
- 3Pick which event maps to which Sched conference
- 4Run the first sync and review before publishing on Sched
What happens when you change a session after the first sync
Sync isn't a one-time push. Once your event is connected, time changes propagate to Sched when you save them on BrightStar, so if a session slips because the room before it ran long, you fix it in one place and it's fixed everywhere. Cancellations work differently on purpose: a cancelled session is marked cancelled on Sched rather than silently removed. If an attendee saved that session to their personal schedule, a session that vanishes without explanation looks like a bug or a missed alarm. A session marked cancelled tells them plainly what happened, so they can go find something else in that slot instead of showing up to an empty room.
Why ticketing and the schedule stay separate systems
It would be simpler, on paper, for one system to run both the public schedule and the door. BrightStar keeps them apart deliberately. Sched is built for browsing a lineup, not for checking someone in or enforcing capacity, and asking it to do both would mean your entry logic depends on a second product's uptime and syncing behavior. By keeping BrightStar as the only place that governs tickets and access, a sync hiccup on the Sched side stays a display issue — an attendee might see a slightly stale session list for a moment — rather than a door issue. That separation is also why the setup asks you to review the first sync before publishing: it's the one point where a mapping mistake could show the wrong sessions to attendees, and reviewing before it goes live catches that before anyone sees it.