Guides
Task-shaped walkthroughs that take an organizer from an empty Organization to a published Event and a scanned door
Each guide follows one organizer job from start to finish, in the order the work actually happens. They assume the vocabulary in Concepts and the rules in Reference; they do not repeat them.
Create an Event
Fill in a draft Event and its Passes in an order that avoids rework.
Publish an Event
The checklist publishing validates, and what changes once it passes.
Sell Passes
Sale windows, capacity, holds, discounts, and the ways a sale fails.
Run Check-In
Configure a checkpoint, scan credentials, and read every rejection.
Invite Your Team
Invite Members, choose Roles, and scope authority to one Event.
Export Your Data
Run a Report, export a CSV, and schedule a digest.
The order these sit in
Creating and publishing are one-way in practice: a draft Event is private work, and publishing turns it into something a buyer can find, read, and pay for. Selling, admission, and reporting all depend on that published record, so the guides follow the same sequence an Event does.
If you are setting up a new Organization, start with the first guide and stop at publishing. Nothing about team structure, exports, or admission needs to be configured before an Event exists, and a simple single-Pass Event should not require any of it.
What you need before the first guide
- An Account. There is no separate signup: verifying an email or phone resolves an existing Account or creates one.
- Membership of the Organization. Attendance never grants this. Membership is what lets an Account act inside an Organization, and it carries the Roles that decide what the Account may do.
- The right Capability. Every step below is gated by a named Capability — publishing an Event, creating a Pass, dropping a refund. If a screen is missing, the cause is usually a Role, not a bug.
- KYC and settlement for a paid Event. Drafting is unimpeded; publishing a paid Event is not. Free Events need neither.
Guides describe jobs, Reference describes rules
A guide answers "what do I do next". A reference page answers "what is allowed, and what happens when it is not", usually with the transitions and preconditions spelled out. When a guide and a page disagree about a rule, the reference page is the one written to be normative.
- Event state, transitions, and who may trigger them: Event status
- Public, unlisted, and private: Event visibility
- What publish validates and freezes: Publishing rules
- Individual versus team entry: Participation mode
- Refund obligations on cancellation: Cancellation
- Currency, tax, and fee arithmetic: Pricing and tax
- Roles, scopes, and API keys: Capabilities
- Gates on payment and admission: Requirements
Where something is not available yet
Ulsav is delivered in vertical slices, so a few described behaviours are scheduled rather than shipped:
- offline check-in acceptance,
- reserved seating,
- a custom report builder,
- PDF report formats.
All four are deferred in the product scope and the delivery roadmap. Pages mention this where it matters instead of describing the feature as if it were live.