Self sign-up with access control
Self-Registration for Events
Letting attendees sign themselves up, while organizers decide who gets in.
Context
Professional · Pigeonhole Live
Role
Product Designer
Team
With the CEO & product managers
Timeline
On and off, shipped 2025

Overview
What it is
Self-registration for Pigeonhole Live events. Attendees sign themselves up through a link, and organizers decide who can enter. Shipped in 2025 as part of the Enterprise plan, after being postponed several times.
Who it’s for
Organizers on the Enterprise plan, including those using single sign-on (SSO), and everyone joining their events: attendees, staff and vendors.
What I did
I mapped every way an attendee can enter, then designed the registration flow, organizer controls, confirmation screens and error states. What counts as a “registrant” was redefined with the CEO and product managers.
Focus Areas
Workflow Design, Information Architecture, Interaction Design
Design Methods
System and user flow mapping, edge-case mapping, design reviews with leadership
The problem
It looked like a form. It was really about who gets in.
Before this, organizers had to upload attendee lists by hand. That didn’t scale for public events, and single sign-on (SSO) alone wasn’t enough: event staff or vendors without a company login couldn’t get in easily. Many clients were asking for a better way.
The form itself was simple. The hard part was everything around it. Attendees could arrive through SSO, an embed in another platform, a direct link, an attendee code or an organizer’s upload, and every route had to end with the right person in the right profile. We set four goals.
01 Attendees register themselves
Through a simple form, without waiting for an organizer to add them.
02 Organizers set the window
They decide when registration opens and how long it stays open.
03 Events can be locked
Only registered attendees, with SSO or without, can enter.
04 SSO events can let others in
Organizers using SSO can still allow guests without it, like vendors or event staff.
My approach
Mapping every way in, before designing a screen
I started by mapping every type of attendee and how they enter. That way the form, the access rules and the edge cases would behave the same, whichever route someone took.

Registration system flow. Purple: how attendees enter. Blue: what the system checks. Click to enlarge. Open full size ↗
01 Seven ways in
An embed, a registration form or a direct link, each with or without SSO, plus attendees uploaded by the organizer.
02 Checks along the way
Does the platform pass a user ID? Is there an email? Is it on the registrant list? Each answer decides the next step.
03 One profile at the end
Every route ends with the attendee logged into one profile. When an email matches several, clear rules pick one.

Close-up: when one email matches several profiles, the system picks the latest signed-in one first, then a unique match, then the one with the most information.
The same logic, from the attendee’s side
The user flows follow attendees from an external platform or a direct link, with and without SSO. The notes on each branch list the real situations behind it, like an organizer uploading the same person twice.

User flows, from entering Pigeonhole Live to being logged in. Click to enlarge. Open full size ↗

Close-up: each branch lists why it can happen, such as an attendee who registered elsewhere or signed in on another platform.
Design decisions
Three decisions that shaped the feature
Each one comes back to the goals above.
01
Redefine who counts as a registrant
Before, a “registrant” only meant someone the organizer had uploaded. Once attendees could sign themselves up or arrive through SSO, that definition no longer covered everyone who could rightly get in.
Because this was for the Enterprise plan, the top tier, the CEO and product managers reviewed it closely. Together we redefined a registrant as anyone with a valid profile, through SSO or otherwise. Locked events, confirmation screens and the edge cases all build on that one definition.
What it enabled
One definition the whole system could rely on, whichever route an attendee took.

Registration review with the CEO and product managers. Colleagues’ faces are blurred.
02
Organizers decide how open or strict entry is
Some events are public and want anyone to sign up. Others are internal and only want people with a company login. One fixed rule wouldn’t fit both.
Turning on self-registration generates a registration link and locks the event to registered attendees. Organizers set when registration opens and closes, or keep it always open, and can change access while the event is live. With SSO, they can let in only registered SSO attendees, or allow a non-SSO login so partners and vendors can still get in.
What it enabled
The same feature works for a private all-hands and a public conference.

Self-registration settings: a generated link, and a registration window that can be set to always open. From Pigeonhole Live’s help centre.

Access control: organizers can let in only registered SSO attendees.
03
A confirmation screen that adapts
After registering, attendees need to know they’re in and how to get back in later. That depends on how and when they registered.
If the event hasn’t started, registrants see a confirmation page. If it’s already live, they go straight in. When email is required, they also get a confirmation email with sign-in details. Organizers choose whether the page offers an early “Enter event” button and a calendar file. Each attendee gets a private link with a reminder not to share it, and if email isn’t required, the attendee code is shown on screen.
What it enabled
Attendees leave registration knowing when the event is and how to get in.

Confirmation on mobile. Mockup with sample branding.

Organizers choose what the confirmation page shows. From Pigeonhole Live’s help centre.
Edge cases
What happens when things don’t go to plan
No email required
The attendee code is shown on screen, so they can still get back in.
Registration closed during the event
The attendee is blocked or rerouted, instead of reaching a dead end.
Back before the event starts
They see a “You’ve registered” page, not the form again.
SSO only, no fallback
Access stays strict: only people with the company login get in.
Code or email not on the list
They see an error screen instead of being let in.
Results
What shipped
Self-registration shipped as part of the Enterprise plan. These are the parts that made it work for real events.
01
Hard-to-guess links
Registration form links are obfuscated, to keep out unwanted sign-ups.
02
Branded confirmation
Confirmation screens carry the organizer’s branding, the event details and a calendar invite.
03
Rules that change live
Organizers can tighten access during the event, like only letting in pre-registered SSO users.
04
Another way in for SSO events
If enabled, guests without SSO get an alternative login, which helps third-party partners join.
Expected impact
Organizers no longer need to upload every attendee list by hand, and attendees get a simpler way in, especially on mobile. That was the point: many clients had asked for exactly this.
What I learned
Most of the work was mapping how people get in
What worked
Giving organizers control over how people join made a big difference. Letting attendees register themselves made large and public events much easier to run.
What was hard
Mapping every way people could enter (SSO, links, codes, uploads) was more complicated than expected. Every route had to work smoothly for organizers and attendees alike.
Next time
I’d give organizers clearer feedback, like a live count of registrations, and tools to send reminders or updates from the dashboard.