How to build an event check-in app in an afternoon

Who this is for: event managers and anyone who has stood at a registration desk with a highlighter. What you'll need: Power Apps, and your registrations in Dataverse. Check the licensing note in step one before you start. How long: an afternoon. What you'll have: an app on a phone or tablet that marks attendance against the real record.

What check-in actually needs to do

Less than you think. A queue of eighty people at nine in the morning wants one thing from you: to be found quickly and let in.

Find a name. Mark them arrived. Handle the person who isn't on the list. That's it. Every additional feature you put on that screen is a second added to every single check-in, multiplied by everyone in the queue.

The reason to build it rather than use paper isn't speed at the door. Paper is fast. It's that on Monday the attendance is already against each member's record instead of being a stack of highlighted sheets somebody has to type up, badly, three days later.

Step one: check the licensing before you build anything

This is a five-minute check that saves an embarrassing conversation later. A canvas app reaching Dataverse uses a premium connector, which needs the right Power Apps licensing for everyone who will use the app.

That's usually a small number, the two or three people on the door, so it's rarely expensive. But it isn't included in a basic Microsoft 365 licence, and finding that out at 8:45am on conference day is a genuinely bad start.

Ask whoever manages your Microsoft licensing whether the people running your registration desk can use a Power App that connects to Dataverse. Do it now, not after you've built it.

Step two: create the app and connect it to your registrations

1. Go to make.powerapps.com and sign in.
2. Choose Start with data, then your Dataverse table of event registrations or bookings.
3. Power Apps generates a three-screen app: a list, a detail view and an edit form. Most of it is more than you need, and that's fine. You're going to strip it back.
4. Save it with a name that says which event it's for, and preview it on your desktop to check the records are appearing.

If your registrations sit in more than one table (say, member bookings and non-member bookings separately), build against one first and get it working. Combining them is a second afternoon, not part of this one.

Step three: make the search work the way a door works

The generated app searches, but probably not on the right thing.

1. Select the gallery on the list screen and find its Items property.
2. Set the search to match on surname first, then first name, then organisation. Surname is what people say at a door and what's printed on the badge.
3. Make the search box the biggest thing on the screen. Somebody is using this one-handed while talking to a delegate.
4. Show four things per row and no more: name, organisation, ticket type, and whether they've already arrived. Anything else is noise at speed.
5. Sort the list so nobody already checked in appears at the top. You want the people still to arrive in front of you.

Resist QR codes on the first build. They're faster in theory and in practice you spend the morning explaining to people that the code is in the email they didn't print. Surname search never needs explaining.

Step four: one button, and make it obvious

Marking somebody arrived should be a single tap from the search result, not tap through to a detail screen, then edit, then save.

1. Put a button directly on each row of the gallery, labelled Check in.
2. Set it to patch the record: mark attended, and stamp the time. The timestamp is free and tells you afterwards when your queue actually peaked.
3. Change the row's appearance once somebody is checked in: a tick and a lighter background. The person on the door needs to see at a glance that the tap worked.
4. Add a way to undo. Somebody will check in the wrong Smith, and they will do it in the first ten minutes.

Step five: the walk-ups, which is where the money is

Somebody will turn up who isn't on the list. A colleague of a delegate, a late booking that never synced, a speaker's guest. On paper they get written on the back of a sheet and lost.

Give the app a second button, Add walk-up, that captures name, organisation and email, and creates a record marked as a walk-up.

This is worth more than the rest of the app combined. Non-member attendance is how a real share of recruitment happens, and it's precisely the group that disappears when check-in is paper. Four names captured properly at a door are four follow-ups next week.

Step six: test it where the event actually is

Conference registration desks are in basements, in marquees, and in listed buildings with three-foot walls. Signal is the thing that ruins this.

1. Install the app on the actual phone or tablet you'll use, not just your desktop preview.
2. Take it to the venue if you can, or somewhere with genuinely poor signal, and try to check somebody in.
3. If it's slow or fails, arrange a hotspot or ask the venue for wired guest wifi at the desk. Ask early. Venues are slow about this.
4. Print a paper list anyway. Not as a fallback you expect to use, but because the one time signal dies completely, an event manager with no list has a very public problem.

Power Apps has offline capability, but it is fiddly and this is not the app to learn it on. A hotspot at the desk solves the same problem in five minutes.

What you get on Monday

Attendance against each member's record, without anyone typing anything. So you can answer, without an afternoon's work, who came, who booked and didn't, and how many attendees weren't members.

The no-shows are the more interesting list. A member who books events and stops turning up is showing you something months before their renewal does.

And the timestamps tell you when your queue peaked, which is how you decide whether you needed three people on the door or two.

Do this yourself, or have it done

Build it. Genuinely. It's a satisfying afternoon, event managers make far better decisions about a check-in screen than developers do, and you'll be using it at your next event.

Where we help is the rung above: when the app has become how you run every event, and it needs to handle multiple sessions, badge printing, name changes on the door and someone other than you being able to fix it in November. That's Maintain and Evolve, and if you've already built one that the team relies on, we'd far rather adopt it than replace it. It already encodes everything you learned at the last four events, which is not something anybody could write down from scratch.