Create and launch an event
From a public application to a signed contract to a live, on-sale event.
Owned by Host / Promoter · 15 steps · about 25 minutes
Why this exists
This is the workflow the whole platform is shaped around, so it is worth understanding the design before the clicks.
An event is not created by staff. There is no "new event" form a manager fills in on a promoter's behalf. The event is converted from the promoter's own application, and the promoter's user account and event-scoped grant are created by that conversion. The reason is accountability: every event traces back to a specific application, submitted by a specific person, with the numbers they themselves committed to. Staff approve, price and publish — they do not invent.
The contract is the gate, not a formality. Approval drafts a contract automatically; locking it freezes a canonical rendering and takes its SHA-256 hash; the promoter signs a tokenised link; an admin counter-signs. Only the counter-signature flips the event from draft to announced. So an event cannot go public before both parties have signed the exact document that was hashed — which is why locking is irreversible-ish and why the seal stores the hash rather than a promise.
Built behaviour worth knowing: the counter-signature moves the event draft to announced. There is no contract_pending or approved event status in this platform — announced simply means publicly visible. Going on sale is a separate, deliberate admin action afterwards.
Before you start
- Nothing at all to start: the application form is public and needs no login.
- A venue manager or admin session to review and approve the application.
- An admin session to lock and counter-sign the contract, and to put the event on sale.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| host_promoter | host@club.test | host123 | the seeded promoter; already holds a scoped host grant on demo-event-0001 |
| venue_manager | manager@club.test | manager123 | can review and approve applications, but cannot lock or counter-sign |
| admin | admin@club.test | admin123 | the only persona that can counter-sign and transition the event |
Steps 1–3 — Host / Promoter
their manual →-
1Open the public host application form. No account, no login, nothing to set up first.Expected result The form loads for anyone. If you happen to be logged in already, it prefills what it knows about you.Watch out for Returning hosts get suggested values highlighted in red — the platform will not accept them until you explicitly confirm each one, and that confirm gate is enforced on the server, not just in the browser.
-
2Submit the application: the date you want, your expected headcount range, your projected average ticket price, and the flags for live music, alcohol, a late finish and whether you want a ticket royalty.Expected result You get an application id back and the status is new_submission.Watch out for Those flags are not decoration. Each one automatically injects a rider into the contract later, so a wrong flag here becomes a wrong clause in a document you will be asked to sign.
-
3Land on the thank-you page and keep the link. It is your window into the application while staff review it.Expected result You can see the status, and an edit link if staff ask you for more detail.
Steps 4–7 — Venue Manager
their manual →Reviews the application, chases missing detail, and approves it.
-
4Open the intake queue. New applications sort to the top with their viability score.Expected result A list of applications with status and score.Watch out for The score is a scorecard, not a decision. It weights date, headcount and projected revenue — it does not know that the promoter's last night was a disaster.
-
5Open the application and read the whole scorecard: the proposed date against the calendar, the headcount against the room, the rider flags, and any attachments.Expected result The full application with its status history, notes and the rider summary the contract will be built from.
-
6Approve it.Expected result Status moves to approved and — in the same transaction — a draft contract is created automatically, with the riders your flags implied and the headcount, ticket price and event date snapshotted into it.Watch out for Approval is the moment the contract exists. If the contract engine were to fail here, the approval itself rolls back: there is deliberately no state where an application is approved but has no paperwork.
-
7Convert the approved application into a draft event. This is also what creates the promoter's user account (if they did not have one) and grants them a host role scoped to this event id.Expected result A draft event, and a promoter who can now log in and see exactly one event: theirs.Watch out for The grant carries the event id. The promoter is not 'a host' in general — they are a host of this event only.
Steps 8–9 — Admin
their manual →Locks and counter-signs the contract, then puts the event on sale.
-
8Open the drafted contract. Check the auto-injected riders and fill in any variable still blank — headcount, ticket price and event date are rendered inline in blue.Expected result A section-by-section editable document; every edit you make is recorded as a redline.Watch out for A missing variable blocks the lock. That is the intended failure: an unpriced contract must never reach a signature.
-
9Lock the contract.Expected result The document is rendered canonically, hashed with SHA-256, and a tokenised signing link is emailed to the promoter.Watch out for Locking is the point of no return for the wording. Everything after this signs the hashed document — if the wording is wrong, unlock and re-lock rather than editing around it.
Steps 10–11 — Host / Promoter
their manual →-
10Open the signing link from your email. It needs no login — the token is the credential.Expected result The full agreement, exactly as locked, with your rider clauses and your numbers.Watch out for The link expires. If it has, ask for it to be resent rather than hunting for another way in.
-
11Sign it.Expected result Your signature is recorded against the locked hash and the contract moves to awaiting counter-signature.Watch out for You are signing the hash. If the document you are reading were altered afterwards, the seal would not verify — which is exactly the guarantee the hash exists to give you.
Steps 12–14 — Admin
their manual →Locks and counter-signs the contract, then puts the event on sale.
-
12Counter-sign on behalf of the venue.Expected result The contract seals into an immutable hash-verified document, and the linked event flips from draft to announced in the same transaction.Watch out for Announced means publicly visible, not on sale. Nobody can buy yet — that is the next step, and it is separate on purpose.
-
13Open the event dashboard and set up what the customer will actually see: tiers, prices, capacity and the release schedule.Expected result The event with its tiers, zone mapping and availability.
-
14Transition the event to on_sale.Expected result The event is live; the storefront shows it as buyable and the marketing rules watching for it can fire.Watch out for This endpoint is admin-only. A venue manager gets a 403 here even though they can see the dashboard — putting inventory on sale is a money decision.
Steps 15 — Member
their manual →The reason the whole thing exists — they are who finally sees it on sale.
-
15Look at the event as a customer does, and buy one. Nothing in the manual is finished until you have seen the thing you built from the outside.Expected result The public event page with live tiers and a working buy button.