When you start a new event on BrightStar, you are not handed one long form to fill in top to bottom. You get one question per screen, and each answer you give becomes part of the picture the next screens can draw on. That matters most at the two screens that come last: cover art and tickets. By the time you reach them, BrightStar already knows what kind of gathering you are running, who is on the bill, and what you have written about it, so the suggestions you see there are built on your actual event rather than a generic template. This is why the cover step is placed after the description step, and why tickets sit at the very end of the sequence — the order is designed so pricing and imagery decisions get made with full context already saved.
The steps you always see
Every event, on every plan, moves through the same core sequence:
- 1Start — choose the event type and how you want to build it
- 2When — date, time and schedule
- 3Where — venue and location details
- 4Artists — the performers and teachers on the bill
- 5Organizers — you, plus any co-organizers hosting alongside you
- 6Details — title, description and highlights
- 7Cover — the event image
- 8Tickets — pricing and ticket types
Choosing tools instead of wading through them
Once you finish the core sequence, BrightStar asks whether you want to add revenue tools before you move to review. Stay on the free Seva plan and there is nothing else to decide: your event goes straight to review and publishes with the core steps you just completed. Move up to Elevate and you land on a chooser screen first — a single screen where you tick the tools you actually want for this event, things like cart recovery, discount codes, ticket categories, add-ons, attendee questions and reminders among others. Only the tools you switch on get their own configuration step afterward. Skip cart recovery and you never see a cart recovery screen; turn on discount codes and that screen appears asking you to build them. This is why two organizers on the same plan can end up with very different numbers of screens — the flow is shaped by what each event actually needs, not by a fixed list everyone clicks past. You can come back later and switch on a tool you skipped the first time, and its configuration step will appear then.
Editing after you publish
Publishing an event does not close the wizard behind you. If you reopen a published event to change something, BrightStar loads its saved answers back into the same setup flow, and every step you went through the first time becomes a section you can jump to directly — the date screen, the venue screen, the ticket screen, whichever one you need. You do not have to click through the whole sequence again just to fix one field. The one thing that does not reappear is the decision-making part of the flow: the upgrade prompt about revenue tools and the tool chooser itself are left out of the editable list, because there is nothing on those screens to edit — they are choices you already made, not content that describes your event. Separate from the wizard, every event also has a manage page, which is where the live side of things lives: watching sales come in, seeing who has registered, and running the event day to day. The wizard is for building the event; the manage page is for running it once people are actually buying tickets.
What publishing actually writes
Hitting publish does more than save a page for the public to see. BrightStar writes the event record itself, and alongside it, a separate row for every ticket type you set up, a separate row for every attendee question you added, and a separate row for every discount code you created. Each of those becomes its own object inside BrightStar rather than a detail buried inside the event description. That separation is what makes the rest of the platform useful once your event is live. Because a ticket type is its own record, it can be paused, re-priced or reported on without touching anything else about the event. Because a discount code is its own record, its redemptions can be tracked individually so you can see which one actually sold tickets. Because an attendee question is its own record, the answers people give at checkout can be exported per attendee rather than left sitting inside the event page. None of that would be possible if publishing simply saved one page with everything flattened into it.