Issue a VIP walk-in override

Let somebody in who is on no list — recorded as an override, with a reason and a name against it.

Owned by Door Staff · 10 steps · about 12 minutes

Why this exists

Every venue has the moment: someone the owner knows walks up, they are on no list, and they are coming in. The platform's position is that this is fine and entirely normal — and that it must leave a record. So instead of a back door, there is an override: a first-class action that mints a real comp ticket and a real pass, checks the guest in, and writes a row naming who authorised it, why, and on which device.

The difference this makes is only visible weeks later. 'We let forty people in on the list' and 'we let forty people in and here is who authorised each one' are very different conversations to have with an owner or an auditor, and the second one is only possible if the door never had a way to admit somebody silently.

The cap is the interesting piece of design. Overrides run against a per-event house bucket that is exempt from normal allocation, but door staff are limited by a per-event cap, defaulting to ten. Managers and admins are not blocked by the cap — their overrides still count toward it and are audited identically, they just are not refused. The cap is therefore not a security control, it is a forcing function: past ten, a manager has to be physically involved in the decision.

Note what the built system does not let a manager do. Turning overrides off, or changing the cap, is admin-only — the settings panel does not even render for a venue manager. If the cap is wrong for your venue, that is a conversation with an admin before doors, not a fix at the door.

Before you start

  • An employee session and an event selected on the guest-list door screen.
  • The event must be live — a draft, cancelled or completed event refuses an override outright.
  • Overrides must be enabled for the event (they are on by default, cap 10).

Practise with

PersonaEmailPasswordNote
door_staffdoor@club.test door123door shift account: scanner + guest list, nothing else
venue_managermanager@club.test manager123shift lead: implies door_staff, plus intake, sales, guest list, marketing
adminadmin@club.test admin123the only account that can touch money, identity and contracts

Steps 1–5 — Door Staff

their manual →
  1. 1
    Search the guest first. An override is for someone who is genuinely on no list — not a shortcut past a red scan.
    /scanner/guestlist guestlist
    Expected result No matching entry.
    Watch out for If they ARE on the list but the check-in refused, an override is the wrong tool. Read the refusal reason: a revoked pass or a refunded order is not fixed by minting a second ticket.
  2. 2
    Read the override counter on the event card before you start: it shows used against cap, and turns amber with Cap reached — get a manager when you are out.
    /scanner/guestlist guestlist
    Expected result A counter such as overrides 3 / 10.
    Watch out for If the card shows overrides disabled, stop. The endpoint will refuse with 403 overrides_disabled for everyone below admin, and no amount of retrying changes that.
  3. 3
    Press + VIP Walk-in to open the form. Fill in the guest's name, optionally their email, the tier the comp should be issued against, the number of extra guests, and — required — the reason.
    /scanner/guestlist guestlist
    Expected result The Add VIP Walk-in form with name and reason marked required.
    Watch out for The reason field is not decoration and it is server-enforced: a missing name or reason is a 422. Write what you would want to read in three weeks — 'owner guest', 'artist manager', 'comped after door error' — not 'ok'.
  4. 4
    Submit with Issue pass and check in. In one transaction this creates the entry against the house override bucket, mints the comp tickets, issues their passes and checks the party in.
    /api/guestlist/door/{event_id}/override POST guestlist
    Expected result An override id, the entry, the tickets, and the passes with their serials and zones.
    Watch out for Extra guests are capped at five per override. If somebody wants a party of nine through this form, that is a manager decision, not five overrides in a row.
  5. 5
    Understand the two refusals you will actually hit. 409 override_cap_reached means you personally are out of overrides — get a manager, whose own override will go through. 409 event_not_active means the event is not live, and it is checked before any comp inventory is spent.
    Expected result A clear refusal rather than a half-created guest.
    Watch out for The cap only blocks door staff. A manager standing next to you is not exempt from being recorded — their override is audited identically — they are just not refused.

Steps 6–8 — Venue Manager

their manual →

Is not blocked by the door cap, and owns the override report the next morning.

  1. 6
    When the door is capped out, issue the override yourself from the same screen, with your own reason.
    /api/guestlist/door/{event_id}/override POST guestlist
    Expected result The override goes through, with your account recorded as the actor and your role snapshotted on the row.
    Watch out for Your override still increments the used counter. The cap is a signal about the night, so do not treat your exemption as a reason to stop counting.
  2. 7
    The morning after, pull the override report for the event. This is the canonical walk-in record.
    /api/guestlist/events/{event_id}/overrides guestlist
    Expected result One row per override with the guest, the tier, the plus count, the reason, the device and who authorised it.
    Watch out for Comp inventory is real, so overrides show up in the event's sold numbers. If the sales board looks off by a dozen, check here before you go looking for a bug.
  3. 8
    Cross-check the audit tab on the event's guest-list dashboard, which carries the door_override actions alongside every other guest-list action of the night.
    /admin/guestlist/{event_id} guestlist
    Expected result An append-only timeline.
    Watch out for The door-override settings panel is not on this page for you — it renders for admins only. You can see the cap on the door screen; you cannot change it.

Steps 9–10 — Admin

their manual →

Is the only role that can enable, disable or re-cap overrides for an event.

  1. 9
    As an admin, review the per-event override settings: whether overrides are allowed, the door-staff cap, and the default tier comps are issued against.
    /api/guestlist/events/{event_id}/settings guestlist
    Expected result The three settings, with defaults of allowed, cap 10 and no explicit tier.
    Watch out for With no default tier set, overrides fall back to the event's first tier. On an event whose first tier is the expensive one, that quietly comps VIP seats — set the tier before a big night.
  2. 10
    When rehearsing the flow in a demo, reset the override cap rather than burning through it.
    /debug/guestlist/reset-override-cap/{event_id} POST guestlist
    Expected result The usage figures back to a workable state.
    Watch out for Resetting the cap does not delete the overrides you already issued — the audit rows and the comp tickets stay. It only makes the counter stop refusing.