Event check-in and attendance

What it does

Check-in records are the difference between who said they'd come and who actually turned up. For virtual events streamed through Teams, the platform creates them for you when an attendee uses their personalised join link. For in-person events, you get a QR code containing the registration ID and nothing else.

Key facts

Check-ins live on the event record under Registration and attendance > Event check-ins, with a time and date stamp per attendee.
For Teams-streamed events, a check-in is created when the attendee uses the Join in Teams button in an email, or the join button in the Add to Calendar iCalendar attachment.
There is a 120-minute rule. If someone clicks the join button more than two hours before the event start time, no check-in is created. Early birds simply don't register as attended.
Check-ins are post-processed. Expect up to four hours after the event ends before they appear. Separately, the Teams webinar v2 documentation says engagement data is populated about ten minutes after the webinar ends — the two figures aren't reconciled in the docs, so plan for the longer one.
Leave times are only generated automatically for events streamed as Teams webinars. Meeting-type events give you join data but not duration.
The contact must be registered for the event before the Join email goes out. Register someone afterwards and their link won't produce a check-in.
The link is personalised per attendee. Forwarded invitations do not work — the second person joins the meeting but generates no check-in, or worse, checks in as the original registrant.
The email carrying the join link has to be sent from Customer Insights - Journeys with tracking enabled. A join link pasted into an Outlook message produces nothing.
Teams meeting policies on the tenant have to allow the configuration you've chosen, or the join behaviour changes and the check-in doesn't land.
For in-person check-in, each event registration record has a unique ID encoded into a QR code. Microsoft's own documentation is blunt that this is only an ID: verification, the check-in action and any badge printing need custom development.
Session registrations are separate records from event registrations, and per-session attendance is not a first-class check-in concept in the same way.

When to use / skip

If the client runs virtual events on Teams, this is essentially free and you should wire it up — attendance data feeding lead scoring and follow-up journeys is the main reason to run events in this product rather than Eventbrite.

For in-person events, be honest about what's here. A QR code containing a registration ID is a building block, not a check-in app. Small events are better served by an events team ticking names off a view on a tablet, which works today with no build. Anything with badge printing, queue management or offline operation at the door needs either a partner product or a canvas app someone has to build and maintain. Don't let a demo of the QR code imply a working door process.

Configuration decisions

Whether attendance matters at all, or registration is the metric the business actually reports on. This decides how much of the below you build.
For virtual: which Teams meeting type, because it determines whether you get leave times and duration or just a join event.
How the join link reaches attendees — reminder email, calendar attachment, or both — and how close to the event, given the 120-minute rule.
For in-person: manual check-in from a view, a custom app over the QR code, or a third-party scanner integration. Budget accordingly.
Whether session-level attendance is required, and if so how it's captured, since it isn't handled the way event check-in is.
What downstream consumes check-ins — lead scoring, a post-event journey, a report — and therefore how much the four-hour lag matters.

Gotchas

The 120-minute window quietly loses attendance for anyone who joins early to test their audio, which is exactly the behaviour organisers encourage.
The post-event lag means a "thanks for attending" journey firing an hour after the event will miss most of the audience. Delay the branch, or trigger on something else.
Forwarded join links are common at corporate clients where an EA books for an executive. The attendance data will be wrong and nobody will know why.
Registering someone on the day, then sending them the previously-built email, produces no check-in. Late registrations need their own send.
A tenant Teams policy change made by an unrelated admin can break check-in creation with no error surfaced in Customer Insights - Journeys.
Calendar changes made on the Teams side don't sync back to the event record, so a rescheduled meeting can leave the event's times and the actual join window out of step.
The QR code gap is the single biggest expectation mismatch in this module. Clients hear "QR code check-in" and picture a scanner app.

Consultant notes

Say the words "the QR code is just an ID, there is no check-in app" in the first events workshop. Written down, ideally.
For virtual events, demo the join-to-check-in flow end to end in UAT including the lag, so the client sees why the follow-up journey waits.
Push back on real-time attendance dashboards for virtual events. The data isn't real time and promising it will cost you at go-live.
If in-person check-in is in scope, scope it as a proper build with an owner, and check whether the venue has usable wifi before anyone assumes an online app at the door.
Before go-live, verify that the reminder email is sent from the app with tracking on, and that its send timing sits inside the two-hour window relative to event start.

Worth revisiting once the improved attendance reporting Microsoft has been listing for Teams meeting types actually lands — it should change the leave-time and duration story.