Request Access: A Safety Net for Invite-Only Events (Without Opening the Floodgates)

If you've set up invite-only registration for your event, you've probably had this exact worry: what happens when someone who should be there isn't on the list? A colleague forwards the invite to a new hire. A partner asks if their plus-one can come. Someone hears about the event through the grapevine and wants in. With a hard invite-only gate, all of those people hit a dead end — and you don't find out until they email you asking why they can't register.

Request Access is built for exactly that gap. It's a toggle you turn on alongside invite-only registration, and it turns your dead end into a request form. People who aren't on an invite list can still submit their information and ask to attend. You keep full control over who actually gets in — you just stop losing people by accident.

What Request Access actually does

Without Request Access, invite-only registration is simple and strict: if your email isn't on an invite list, you can't register, full stop. That's the right call for a lot of events. But it also means any gap in your invite list — a missed name, a late addition, a forwarded link — becomes a locked door with no way to knock.

Turn on Request Access, and that door gets a doorbell. Someone who lands on your registration page without an invite sees an option to request access instead of just a "you're not invited" message. They fill in their basic info and submit it. Nothing about your invite-only setup changes for people who are already invited — they register normally. Request Access only changes what happens to the people who aren't.

How the request-to-approval flow works

The mechanics are a short loop: someone asks, you decide, and if you say yes, they get a real invite. Here's what that looks like end to end.

Notice that rejecting a request takes one step and approving takes two. That's intentional — approval is the path that requires a decision about where this person belongs, not just whether they're allowed in.

What to ask for on the request form

The value of Request Access depends a lot on whether you have enough information to make a fast, confident call. If all you see is a name and an email address, you're often stuck guessing or emailing the person back before you can decide. A slightly fuller request form saves you that round trip.

At minimum, it's worth collecting:

• Name and email — the basics you need to identify who's asking and where to send the invite if approved.

• Company or affiliation — this alone tells you a lot. A work email from an organization you already work with is a very different signal than a personal email with no context.

• A short free-text field — something like "why do you want to attend" or "who invited you / who referred you." This is the single most useful field on the form, because it's where people tell you the thing you actually need to know: "Jane on the marketing team said I should come," or "I'm the new hire replacing Tom," or "our sponsor rep said to sign up directly."

That free-text answer is what turns a review from a guessing game into a quick, confident decision. "Referred by Jane, marketing" is something you can verify in ten seconds by glancing at your invite list or asking Jane directly. A blank field with no explanation is exactly the kind of request where you should slow down, ask for more detail, or reject and let the person follow up if it's legitimate.

Real situations this covers

Request Access earns its keep in the situations that are common but hard to plan for perfectly in advance:

• The forwarded invite. Someone on your list forwards the invitation to a colleague who genuinely should be there, but wasn't on your original spreadsheet. Instead of that person emailing you confused, they request access and you approve it in seconds.

• The last-minute internal referral. A department head decides two more people from their team should attend, after registration is already open. Rather than you manually re-uploading a list, those two people can request access directly.

• The plus-one who needs sponsor sign-off. A partner or sponsor wants to bring a guest, but you want to approve that guest individually rather than extend blanket access. Request Access gives you a checkpoint without making the sponsor chase you down over email.

• The controlled waitlist. Your event is technically invite-only, but you're open to letting a handful of additional people in if there's room or if they're a good fit. Request Access acts as a soft waitlist — people can ask, and you decide case by case, without ever opening registration to the general public.

In every one of these cases, the alternative without Request Access is the same: someone emails you, you manually check if they should be on the list, and you either manually add them to your invite list and resend an invite, or you tell them no. Request Access just moves that entire conversation into your dashboard instead of your inbox.

Approve or reject: how to decide

Most requests aren't hard calls, but it helps to have a rough rule for the ones that are. Here's a simple way to think about it.

You can always reject a request and follow up separately if you want more context before deciding — rejecting through Sunfish doesn't have to be the final word if you'd rather have that conversation directly.

Why the invite list you pick on approval matters

The extra step on approval — choosing which invite list to add someone to — isn't busywork. In Sunfish, the invite list someone belongs to determines what they see: their pricing group and the registration questions they're asked. That's the same logic covered in how group assignment automates member vs. non-member pricing.

So when you approve a request, you're not just letting someone through the gate — you're deciding what their registration experience looks like on the other side. Approve a partner's plus-one and add them to your "Guest" list, and they get guest pricing and guest-relevant questions. Approve an internal referral and add them to your "Employee" list, and they get whatever pricing and questions your team normally sees. Getting this step right means you don't end up manually fixing someone's price or questions after the fact — it's handled the moment you approve them.

Should you turn it on by default? The wall-vs-doorbell tradeoff

Request Access isn't automatically the right setting for every invite-only event, and it's worth being honest about when a hard wall is actually the better choice.

A hard wall (Request Access off) makes sense when your invite list is genuinely final and you have a strong reason to keep it that way — a board meeting, a highly capped executive briefing, a compliance-sensitive session where "who's in the room" needs to match a pre-approved list exactly. In those cases, the friction of a locked door is doing real work: it stops well-meaning forwards and last-minute additions from creating a mismatch between who registered and who was supposed to be there. If that mismatch is a real problem for you, leave the toggle off.

A doorbell (Request Access on) makes sense for the far more common case: your invite list is a best effort, not a legal document. Most SMB, association, and trade-show organizers build their invite lists from spreadsheets, CRM exports, and "who do we think should come" conversations — and those lists have gaps almost by definition. If your real risk is under-inviting people who should be there, rather than over-inviting people who shouldn't, turning Request Access on is the safer default. You lose nothing in control, since every request still needs your approval, but you stop silently dropping legitimate attendees.

A reasonable rule of thumb: if you'd be upset to discover someone got in who shouldn't have, lean toward the wall. If you'd be more upset to discover someone who should have been there never made it, lean toward the doorbell.

Turning invite-only into a gate with a doorbell

The honest framing here is that Request Access doesn't make your event less controlled — it makes invite-only more livable. A hard invite-only wall protects you from unwanted registrations, but it also silently drops the people you'd actually want at your event if you just knew to add them. A gate with a doorbell keeps the same protection while giving legitimate people a way to knock.

You still make every decision. Nobody gets in without your approval, and nobody gets automatically added to a list without you choosing it. The only thing that changes is that "not on the list" stops meaning "permanently locked out" and starts meaning "ask, and we'll take a look."

FAQ

Does Request Access let anyone register for my event?
No. Turning it on only gives uninvited visitors a way to submit a request — it doesn't register them. They still need your explicit approval, and they still need to be added to a specific invite list, before they can complete registration.

What does a requester see if I reject their request?
They're not sent a rejection notice with details — you control whether and how you follow up with them directly. This keeps the decision entirely in your hands rather than triggering an automated message you didn't write.

Can I set a cap on how many requests I approve?
Sunfish doesn't enforce a numeric cap on requests for you — approving or rejecting each request is a manual decision, one at a time. If you're watching a capacity limit, that's something to track yourself as you review requests, using the same judgment you'd apply to any other approve/reject decision.

Does approving a request notify the rest of my team?
Requests and their status live in your event dashboard, so anyone on your team with access to that event can see what's been approved or rejected there. There isn't a separate notification beyond that — it's the same dashboard visibility you already have for the rest of your invite-only setup.

Can I turn Request Access on or off after registration has already started?
Yes. It's a toggle on your invite-only settings, so you can turn it on if you start seeing missed people show up in your inbox, or turn it off if you want to lock the event down completely for a stretch.

Key takeaways and next step

Invite-only registration protects your event, but it can quietly cost you legitimate attendees if your list has any gaps. Request Access closes that gap by giving uninvited visitors a way to ask instead of a dead end, while keeping every approval decision — and every pricing/question assignment — entirely under your control. Whether you leave it on by default comes down to one question: is your bigger risk letting in the wrong person, or missing the right one?

If you're already using invite-only registration, turn on Request Access in your event settings and see what comes through. If you haven't set up invite-only registration yet, start with the invite-only registration guide and add Request Access once your invite lists are in place.