In short
Four separate settings decide whether a pass works at a given moment: the event window, the days the pass names, the re-entry allowance, and the capacity of the venue. They are independent of one another and a pass has to satisfy all of them. Tiers and seats sit alongside these as labels and change nothing.
The setting that causes the most confusion is the one nobody configures deliberately: the timezone. Every “per day” rule in the system — re-entry counts, duplicate detection, capacity, which named days have been used — is measured against the calendar date in the event’s own timezone. If that has been left alone it is New York, regardless of where the venue is, where the operator is standing, or what the door tablet’s clock says.
On this page
Tiers and seats are labels
Every pass carries a tier. If nobody sets one it reads GA. The field is free text, so a tier can be anything you find useful — Early bird, Crew, Sponsor table 4 — and there is no list to choose from and nothing to configure first.
Because it is free text, it also carries no authority. The gate does not consult the tier when deciding whether to admit somebody. A pass marked Backstage and a pass marked GA are treated identically at the same door. If backstage genuinely needs to be separate, it needs its own gate, not its own tier name.
A seat is the same kind of thing: an optional label, printed on the pass and shown to the operator, with no enforcement behind it.
Use tiers for what they are good at — sorting your reporting, telling operators at a glance who they are looking at, and printing sensible artwork. Use gates, not tiers, for anything that must actually be enforced.
The window and the days are two different limits
An event has a window: a start moment and an end moment. Outside it, nothing is admitted at all, and the gate reports the attempt as being outside the window rather than as a problem with the pass.
Separately, an individual pass may name the days it covers. This is a list of calendar dates held against that one pass, so two people at the same event can hold passes covering different days.
A pass with no named days is not a pass that works on no days. It is a pass that works on any day, as long as the window is open. This is the default and it is the right setting for the overwhelming majority of single-day events — there is nothing to configure.
Naming days — and the typo that costs one
Days are given as calendar dates in the year-month-day form. They can be supplied as a list or as a single comma-separated line, and repeated dates are collapsed to one.
There is a trap here worth being deliberate about. Each date is checked against the expected shape, and anything that does not match is discarded silently. There is no warning and no error. A three-day pass whose middle date was typed as 2026-13-04 is created quite happily as a two-day pass, and nobody finds out until somebody is turned away on the Saturday.
After issuing multi-day passes, open one and count the days. It is a five-second check that catches an entire class of failure which otherwise surfaces at the door, in front of the person holding the ticket.
Whose midnight?
Almost every limit in the gate is counted per day, so the definition of a day matters enormously. It is not the venue’s local time as the operator’s phone reports it, and it is not the time the pass was bought.
Each event carries a timezone, and every entry is converted into a calendar date in that zone before anything is counted. Two entries either side of midnight in the event’s timezone are two different days, and everything resets between them.
If the timezone was never set, or was set to something the platform does not recognize, it falls back to America/New_York. It does not fall back to universal time and it does not adopt the operator’s local zone. For an event in London or Los Angeles this makes the day boundary land in the middle of the evening or the middle of the afternoon respectively, and produces re-entry counts that look inexplicable.
Set the timezone when you create the event, even for a single-day one. It is the single most consequential field on the form and the least likely to be noticed.
Re-entry: single, capped, unlimited
Re-entry governs how many times one pass may come through a door within a day.
| Mode | Behavior | Good for |
|---|---|---|
| Single | One entry per day. A second attempt is reported as a duplicate. | Seated performances, anything ticketed by the seat |
| Capped | A fixed number of entries per day, which you choose. | Festivals with in-and-out privileges you want to limit |
| Unlimited | Come and go freely. | Conferences, trade shows, multi-building venues |
Single is the default, and the allowance defaults to one. An event created without touching these settings is a one-entry-per-day event.
Note the interaction with multi-day passes: the allowance is per day, not per pass. A capped allowance of two on a three-day pass is six entries across the event, not two.
Capacity
Capacity is a ceiling on how many people are admitted in a day. Leaving it unset means unlimited — a capacity of zero is stored as “no limit”, not as “nobody gets in”.
Capacity is only consulted on somebody’s first entry of the day. Re-entries never consume a place, because the person is already counted. This is the correct behavior and it catches operators out constantly: at a full house, people stepping out for air must still be let back in, and the gate will let them.
A door working offline applies the same rules from the pass list it downloaded — the window, the named days and the per-day counts — but it can count capacity only from its own first entries, because it can’t see the other doors until it reconnects. See Operating the gate.
Passes bound to a person
A pass can be issued bound to an identity through Linxy Fusion. Such a pass belongs to that person and to nobody else. It cannot be transferred, and no amount of it being unused changes that — the block on transferring is checked before anything about how spent it is.
This is the tool for credentials that must not circulate: staff passes, accreditation, anything where the name on the pass is the point. It is a deliberate choice at issue time and cannot be added or removed afterwards from the holder’s side.
Draft, active, closed
An event has three states of its own. Draft is where it starts — and this catches people out, because an event created and populated with passes is not yet live. Passes exist, holders can see them, and the gate will not run. Active is the working state. Closed retires it.
Two more settings are fixed at this level rather than per pass: whether operators must confirm their identity biometrically before scanning, and whether the door hardware is expected to be a tablet or a phone.
The single most common day-one support call is an event still sitting in draft. Move it to active the day before, not on the morning.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| Everything is refused as outside the window | The window has not started, has ended, or was entered in the wrong timezone | Check the window and the event timezone together |
| A valid-looking pass is refused on one day only | That day is not in the pass’s list — possibly because of a rejected date | Open the pass and count the days it names |
| Re-entry counts reset at a strange hour | The event timezone is not the venue’s | Set the timezone; counts follow it immediately |
| A pass meant for one day also gets in on the other days | No days were named, so it is good on every day the window is open | Name the days it covers |
| A multi-day pass can’t be transferred after the first day | Its days were never named. For transfers, a pass with no named days is spent on its first entry | Name the days, so the unused ones stay transferable |
| People are turned away at a full house on re-entry | They should not be — re-entry does not consume capacity | Check whether the pass is single-entry rather than blaming capacity |
| Nothing scans at all on the day | The event is still a draft | Set it to active |
| A staff pass will not transfer to a colleague | It is bound to a person | Issue a new pass to the colleague |
Things people commonly get wrong
Related reading: Tickets and passes, Operating the gate, Creating an event, and When something is not working.