Check-in staff used to need a real idloom account each. For an event with 10 or 20 people on the doors, that meant 20 accounts created in advance, credentials handed out, a forgotten password reset at the worst possible moment, and 20 accounts left behind long after the event finished.
There's a second problem with accounts, and it doesn't go away with scale: a back-office login opens the back office. Roles and permissions exist to narrow that down, but they're work to configure and easy to get wrong for someone who's only there to scan badges.
Check-in access solves both. You issue a code, the person scans it, and it reaches exactly one place: the event check-in page. There's no back office to lock down, no permission set to choose, and no idloom user created — no account, no password, nothing in your user list afterwards.
Where to find it
Open your event and go to Check-in. The Check-in access screen lists every code you've issued, and three buttons sit at the top of the page:
- Give access — issues a new code
- My check-in access — your own personal code, for getting the check-in page onto the phone in your hand
- Live dashboard — the live view of check-in while it's running
Use your own check-in access on any device
My check-in access gives you a personal code, ready to use without creating an operator. You already have an idloom account, so this one isn't about avoiding account creation — it's about opening the check-in page on a phone or tablet without logging in again on that device.
Scan the code, or copy the link, and the check-in page opens as you. Nothing is created and no operator is added to the list.
Give check-in access to an operator or a team
Select Give access and fill in the same short form, whether it's for one person or a whole team.
Choose the check-in point
Pick where this access applies: Global check-in for the whole event, or a specific category or option. They can check guests in only at this point.
Choose who it's for
- One person — you name them, and they get their own code. The operator's name appears in the check-in log, so you know who scanned what.
- A team sharing one code — you give the team a name and a number of passes. That's how many people can claim access with this code.
Everyone who claims a pass gets their own individual access. One code, but not one shared login: each person's scans stay attributed to them.
Choose an access level: scanning only or full access
Two access levels, chosen when you issue the code.
- Scanning only — scan badges and check guests in, without seeing email addresses or payment amounts.
- Full access — everything in scanning only, plus email addresses, payment amounts, blocked check-in overrides, and guest editing.
Scanning only is the safer default for temporary staff who aren't your employees, and it's what most people on a door need. Full access suits the person who has to resolve a payment or let a blocked guest through.
Set when check-in access ends
Access ends is prefilled with the end of your event. Change it if your team needs access for less time — a single morning, or one day of a three-day conference.
Manage check-in access codes
The Check-in access screen groups every code by check-in point, and shows how far each one has been claimed.
At the top, a summary of all passes issued splits three ways:
- In use — claimed and working
- Not claimed yet — issued, nobody has scanned it
- No access — expired or revoked
Each team row shows its claimed passes as a fraction — 2/5 means three passes are still available — and expands to list the people who've claimed one, with whether they're currently scanning or idle. Individual operators appear as their own rows. Expired codes stay in the list, greyed out, with the date they ended.
Filters across the top narrow the list by check-in point, status, or access level when the list gets long.
Share or revoke a check-in access
The menu on any row gives you three actions:
- Share code — show or send the code again, for latecomers or a lost phone
- Enable scanning only — drop the access down to scanning only
- Revoke team access — cut off everyone who claimed a pass from that code, in one action
Revoking stops people scanning. It doesn't delete check-ins they already made — those stay on the record, attributed to them.
Watch it happen on the live check-in dashboard
Setting up access is half the job. The other half is knowing, while the doors are open, whether it's actually working — whether the team you set up is scanning, whether one door is falling behind, whether someone let a cancelled registration through.
The live check-in dashboard answers all of that in one screen, updating as it happens.
Arrivals, per check-in point
The top of the dashboard tracks arrivals against how many are expected, split three ways: who's currently on site, who has checked out and left, and who hasn't arrived yet. Below it, every check-in point gets its own progress bar — each session, each category, each option — so a door that's falling behind is visible without doing the arithmetic yourself.
Your operators, and who isn't scanning
The team panel lists every operator with the check-in point they're on and how many people they've scanned. Operators who haven't started yet are flagged as not started — the signal that matters at 8:55 when the doors open at 9:00 and one desk is unmanned.
This is where the access you issued becomes visible: if you gave a team five passes and only two are scanning, you can see it and act on it.
Every check-in, check-out and override
The live activity feed lists what's actually happening, filterable to the parts you care about:
- Overrides — a forced check-in, or a cancelled registration let in anyway, each attributed to the person who did it and the check-in point they were on
- Check-ins and check-outs — the full movement record
- Everything — including failed scans, such as a badge that matched nobody
Because every person has their own access rather than sharing a login, each line in this feed carries a name. That's the payoff of issuing access per person: when something needs explaining after the event, the record already says who did what and when.