Create an Event

A new Event starts as a draft: visible to your Organization, absent from discovery, and deletable for as long as it stays a draft. Nothing you do here reaches a buyer until you publish, so the goal is a draft that passes publishing on the first attempt.

• Starts as

  Draft

  Organizer-visible, absent from discovery

• Deletable

  While it is a draft

  Publishing removes the option

• Requires

  events.create

  A paid Event also needs KYC and settlement, but only at publishing

• Reaches a buyer

  Only after publishing

  Nothing here is public until then

1. 1

   Confirm the Organization is readyCopy Anchor Link

   Every Event starts from its Organization's commercial facts, and none of the rate, bearer, or profile values is set per Event.

   • Preferred currency. One of the currencies Ulsav supports — INR, USD, EUR, GBP, AED, SGD, AUD, CAD — editable until the Organization's first confirmed paid Order.
   • Platform fee. A basis-point rate plus a fixed amount. Ulsav sets both, and Settings → Commercial shows them read-only.
   • Fee bearer. Buyer-paid or organizer-absorbed. Only an Owner can change it.
   • Tax profile. Country, state, city, tax identifier, rate, and inclusive/exclusive flag, shared by every Event with no per-Event override. The Event's own venue sets the place of supply for an in-person Event.

   Creating an Event needs events.create. A paid Event additionally needs completed KYC and a verified settlement account from Settings → KYC & Settlement, but only at publishing, so a missing KYC record never blocks drafting.

2. 2

   Name it and classify itCopy Anchor Link

   • Name and summary. Both are required, and the summary is the line a buyer reads first.
   • Description. Markdown, optional, and the place for the detail a buyer wants.
   • Slug. Generated from the name when you create the Event. The app has no field for it, renaming does not change it, and publishing fixes it for good.
   • Category. Pick one — workshop, conference, screening. It is the single-value format axis, and it cannot change after publication.
   • Topics. Add them if they help discovery. They are a separate multi-value subject axis from one global catalog, freely editable forever, and never inherited by or from an EventGroup.
3. 3

   Set the schedule and timezoneCopy Anchor Link

   • Timezone. Required as an IANA identifier; timestamps themselves are stored in UTC.
   • Start and end. Both required, and the end must fall after the start.
   • EventSessions. They must fit inside the Event's dates. There is no override.
   • After publication. The dates move through Reschedule, not by editing the draft again.
4. 4

   Say how people attendCopy Anchor Link

   • Participation mode. Choose in_person, online, or hybrid. This is what the Event offers; which of those an entry attends is decided per Registration, from the modes each Pass supports.
   • In person. Needs a place: pick an exact Venue from the platform gazetteer, or a City while you finalize. The app never creates a Venue.
   • Online and hybrid. Online needs an access URL; hybrid needs both a location and the URL.
   • Exact address. The exact venue and street address are hidden from public view by default, with a per-Event override.
5. 5

   Decide the entry shape nowCopy Anchor Link

   Three settings describe who may enter and in what shape, all under Settings → Registrations:

   • Team mode — individual only, team only, or both.
   • Team size bounds — on the Event rather than the Pass, and every Pass inherits them.
   • Registrations per Person — several, or one live Registration per Account across the Event.

   Team mode and the size bounds lock at publication. Registrations per Person stays editable and applies to new claims only; tightening it is refused while someone already holds more than one.

6. 6

   Add EventSessions if the Event has partsCopy Anchor Link

   • What it is. A flat scheduled part: a talk, a workshop slot, a competition round, a day segment. It carries its own name, schedule, room, and optional capacity, and sessions never nest.
   • Where. Details → Sessions, before the Passes that reference them.
   • Scope. A Pass covers all sessions — including ones added later — or a selected set, and a selected Pass needs at least one session to be valid.
7. 7

   Create the PassesCopy Anchor Link

   A Pass is the only thing a buyer can purchase.

   • Set the fields. Name, description, offer price, an optional list price at least as large, sale window, capacity, minimum and maximum quantity per Order, and session scope.
   • Attendance modes. A non-empty subset of what the Event offers: a single-mode Pass derives the buyer's mode silently, while a two-mode Pass makes them choose.
   • Approval. Turns checkout into a review, where the entry exists and waits for an organizer decision before it can pay.
   • Capacity basis and pricing basis. Independent. A five-person team on a Pass whose capacity basis is registrations uses one unit of Pass capacity and five units of any Event or Session ceiling, whether it is priced per team or per member.
   • Decide before publishing. Price, capacity, quantity limits, sale window, and session access are frozen once the Event is published. Only the name, description, list price, and approval flag stay editable.
8. 8

   Add gates only where they earn their placeCopy Anchor Link

   Requirements live under Settings → Requirements, and each one names a gate where it is evaluated.

   • What you can require. A complete identity, a verified email, a verified phone, an SSO affiliation, or an email-domain affiliation.
   • Hard or soft. A hard requirement blocks its gate; a soft one only nudges.
   • Gates that are enforced. Before payment, before activation, and before check-in.
   • The gap. An at-selection requirement is saved but nothing asks for it during checkout, so use the Pass's own attendance and quantity rules instead.
   • The Registration Form. It collects answers once and seals them, and it is not a Requirement.
9. 9

   Style it, then check the draftCopy Anchor Link

   Presentation styling is catalogue keys, not raw CSS, and stays freely editable after publication, as do FAQs, contacts, sponsors, and Topics.

   Finally, read the Event the way a buyer would: name, date, venue or access details, Pass names and prices, terms. Publishing validates all of it at once.

RelatedCopy Anchor Link

• Publish an Event — the validation checklist
• Publishing rules — what publish freezes
• Participation mode — individual, team, and one-per-person