Ulsav Docs

Participation Mode

Individual and team entry, attendance mode, team bounds, and the one-Registration-per-person rule

Four settings decide who may enter and in what shape; three contain the word "mode", and all four are independent.

SettingLives onDecides
ParticipationModeEventWhat the Event offers: in_person, online, hybrid
AttendanceModeRegistrationWhat one entry chose: in_person or online
Team mode and boundsEventWhether teams exist, and how large a roster may be
Registration policyEventWhether an Account may hold several live Registrations

A fifth Event setting, fulfillmentMode, decides credential delivery — disabled, link, or account_claim — and is unrelated to any of the four.

ParticipationMode is an offer, AttendanceMode is a choice

The Event says what it offers. A Pass declares the non-empty subset it supports, constrained by the Event:

Event offersA Pass may support
in_person{in_person}
online{online}
hybrid{in_person}, {online}, or {in_person, online}

A Registration then records exactly one AttendanceMode, chosen at creation:

  • A single-mode Pass derives the value server-side; the buyer is not asked.
  • A two-mode Pass requires an explicit choice, and a missing or unpermitted value is rejected.

The mode is immutable: a database trigger rejects a change, roster replacement does not touch it, and changing how an entry attends means cancelling and registering again.

A team is one Registration with one attendance mode, because a team is one entry with one approval decision, one order line, and one capacity reservation.

Changing an Event's participation mode after publication goes through the relocate workflow and records a revision. It does not reconcile existing Pass attendance modes or confirmed Registrations; that reconciliation is a known follow-up.

Individual versus team

Individual

  • Registration kind — individual
  • Participants — exactly one current Participant
  • Display name — the Participant's name
  • Order line — one line per Registration, quantity 1
  • Approval — one decision
  • Pricing basis — per individual

Team

  • Registration kind — team
  • Participants — the purchased number of places, including unnamed ones
  • Display name — the Registration's team name
  • Order line — one line, quantity 1, with membersPerTeam set
  • Approval — one decision for the whole roster
  • Pricing basis — per team or per member

The two shapes share one model. A team is not a separate aggregate and there is no Captain entity: the buyer manages permitted roster actions, and each Participant has their own credential and may claim their own Account.

Pricing and capacity stay independent of shape. A five-person team on a per-member Pass is one Registration, one line, and five Participants. It consumes five pricing units. On Pass capacity it consumes one unit when the Pass counts registrations and five when it counts participants; Event and Session capacity always count Participants.

Team bounds

Minimum and maximum roster size belong to the Event, not the Pass, so one Event cannot sell two incompatible formats; per-Pass quantity limits cover the "four-pack" case instead.

BoundValue
Default minimum1
Default maximum10
Range1 to 100
Lives onThe Event, not the Pass
Editable whileThe Event is a draft
Change after publicationRefused; there is no workflow endpoint

The Pass declares whether it sells individual, team, or mixed entries, and that declaration must fit the Event's team mode. A team checkout requires its active roster to sit within the Event's minimum and maximum, not to equal a separately stored purchased count. membersPerTeam records the count chosen at purchase.

One Registration per person

An Event's registration policy is one of two values.

PolicyRule
multipleAn Account may hold several Registrations across the Event. This is the default.
one_per_accountAn Account may hold at most one pending or confirmed Participant place across every Pass and roster in the Event.

The rule is evaluated against Participant rows that carry an Account. It does not count the buyer named on requestedByAccountId, so an ordinary buyer who has not claimed a Participant place is not limited by it.

Details that follow:

  • Drafts do not count, and cancellation frees the place.
  • The rule is per Event, not per Organization: the same person may hold entries at two Events.
  • Tightening the policy is refused if existing data already violates it. The refusal is a generic 409 registration_policy_conflict; a separate audit read reports how many Accounts conflict before the change.
  • Enforcement runs under a per-Event PostgreSQL advisory lock on every account-attaching path: issuance, transfer, switch, submission, and claim. Two simultaneous claims for the same Account cannot both pass.

What participation never does

  • Paying does not enrol the buyer. If the buyer attends, they occupy a Participant place.
  • Ordinary registration does not match a Participant to an Account by contact. Admin issuance and transfer resolve or provision an Account from the email or phone; a public checkout leaves the Participant unclaimed until an explicit claim.
  • A Participant does not need an Account at all.
  • One Account may hold Participants in different Registrations and Organizations, subject to each Event's policy.

The V1-compatible one-Pass mode

The specification describes an Event-level one-Pass mode bundling authentication, no LINK fulfilment, order quantity one, one active Participant per Account, and disabled transfers. That switch is not implemented.

one_pass is rejected as an invalid registration policy value. The settings that do exist are TeamMode, RegistrationPolicy, and FulfillmentMode; none of them bundles those five rules.

Can a team mix in-person and online attendance?

No. A team is one Registration with one attendance mode, because it is one entry with one approval decision, one order line, and one capacity reservation.

Can a Participant switch between in-person and online later?

No. Attendance mode is immutable; changing how an entry attends means cancelling and registering again.

Does the one-per-account policy count drafts?

No. Drafts do not count, and cancellation frees the place; at most one pending or confirmed Participant place may exist across every Pass and roster in the Event.

Do team size bounds belong to the Pass?

No. Minimum and maximum roster size belong to the Event, so one Event cannot sell two incompatible formats; per-Pass quantity limits cover the "four-pack" case instead.

  • Registrations — Registration, Participant, and approval
  • Passes — the offering that declares supported modes
  • Cancellation — what cancelling an entry does

On this page