Public event registration is useful when you need to collect attendee information from people who are not already on an organizer-managed list. But registration and Guest List admission are separate operational stages. If every form submission is treated as accepted immediately, your team may lose the opportunity to review eligibility, distinguish incomplete or unsuitable submissions and maintain a clear record of what has been transferred. QRGATE keeps the public Registration layer separate from the Event Guest List, with Manual Guest List transfer as the default and Automatic transfer available only when an organizer enables it for eligible Registrations.
The operational problem: a submission is not the same as an accepted Guest
A public Registration Page creates an Attendee Registration record when someone submits the form. It does not create a Guest immediately, and it does not grant Event entry. This distinction matters for conferences, corporate events, agency-managed client Events, associations and venues where the organizer needs a controlled Guest List. Without a defined approval process, teams may confuse New submissions with accepted attendees, treat an unverified record as ready for Invitations or assume that registration itself authorizes admission.
- A public submission may still need verification or organizer review.
- Registration statuses such as New, Approved, Rejected and Waitlist describe the Registration workflow; they are not payment approvals, ticket issuance or guaranteed admission.
- A Registration must have a documented verification basis before it can be transferred to the Guest List.
- Adding a Registration to the Guest List does not automatically send an Invitation or complete Check-in authorization.
What guests and event teams experience when the process is unclear
For prospective attendees, an unclear process can create uncertainty: a form may appear to confirm participation even though the organizer has not accepted the person. A person may also receive inconsistent instructions if one team member treats a submission as a Guest while another keeps it in a review spreadsheet. The issue is especially important for group registrations, where one Registration Contact may add several people but each attendee still needs an individual Registration record and later an individual Guest lifecycle.
- Guests may not know whether their submission is being reviewed, accepted or placed on a Waitlist.
- Event teams may have difficulty separating registration data from Guest data and later RSVP responses.
- Copying names and answers into a second list can create duplicate or unclear conversion records.
- Door staff may receive information about a registrant before the person has completed the normal Guest, Invitation, QR Ticket and validated Check-in workflow.
Why common manual workarounds fall short
A spreadsheet can be useful for a simple review queue, and QRGATE supports organizer-managed Guest Lists and supported Excel workflows. However, a disconnected spreadsheet does not by itself enforce the relationship between an Event Registration and the resulting Guest. It can leave teams manually copying names, checking e-mail status, marking approval in one place and updating the Guest List somewhere else. Those steps make it harder to see which attendee has already been converted and whether public editing should remain available.
- Marking a row as approved does not itself create the correct Event-specific Guest record.
- Manual copy-and-paste can make duplicate conversion or duplicate attendee identity harder to detect.
- A spreadsheet status may not distinguish Registration verification from Guest List conversion state.
- Treating RSVP or payment information as approval can blur separate operational decisions.
How QRGATE separates review, approval and Guest List transfer
QRGATE’s optional Event Registration module provides the public Registration Page, configurable Registration Form and Registration administration layer before the Guest List. In Manual mode, which is the default, the organizer reviews Registration records, updates their supported status and selects eligible attendees for transfer. The Add selected to Guest List action then runs the documented backend checks before creating the Guest record.
- Registration records can use the statuses New, Approved, Rejected and Waitlist.
- The Registration list can show attendee information, Registration Contact, Registered by, verification state, date and time, current status, calculated price and Guest List conversion state.
- Each attendee has a clear conversion state, such as Not added or Added to Guest List.
- QRGATE preserves the relationship between the original Registration and the created Guest and protects the same Registration from being converted twice.
- After Guest List transfer, public Registration editing is locked and the Guest becomes the operational object for the next stage.
The verification basis behind an eligible Registration
Approval should be considered alongside eligibility, not as a substitute for it. For a self-registration, the attendee must verify their own e-mail address. For an attendee added by a group Registration Contact, the supported basis is a verified Registration Contact who was authorized to add the attendee. This does not mean that every attendee’s own e-mail address has been verified. An attendee can later use the secure self-claim workflow to verify their own address and take over management of their personal Registration details before Guest List transfer.
- Self verified means the attendee has verified their own e-mail address.
- Verified Registration Contact means the group submission came from a verified and authorized contact.
- Registration Contact verification is not the same as verification of each attendee’s personal e-mail.
- Pending verification should remain visibly different from a verified basis in the organizer’s Registration review.
How the QRGATE modules cooperate
The workflow is designed around one Event context. Event Registration collects and stores the submission. Registration Contact and Attendee Registration records preserve group and individual relationships. The Guest List receives only the eligible attendees that meet the selected transfer policy. After transfer, the Guest record supports the normal Invitation, optional RSVP, QR Ticket and validated Check-in lifecycle. Keeping these modules connected means the original Registration remains available as the historical and relational source while the Guest becomes the operational record.
- Event and Registration Settings define whether Registration is enabled, the timing, capacity and transfer mode.
- Registration Form Builder collects standard fields and supported custom questions for review.
- Registration and Guest List conversion state show what has happened to each attendee.
- Invitation remains a separate organizer workflow after transfer.
- RSVP records participation intention, while Check-in records the validated Event entry result.
A practical event registration approval workflow
For a hypothetical corporate conference, the organizer can publish a branded Registration Page and collect attendee details from employees, partners or clients. The following sequence keeps review and transfer explicit.
- 1. Enable Event Registration for the Event and configure the Registration opens and closes dates, maximum attendee capacity and any public availability display.
- 2. Configure the Registration Form with the standard fields and any relevant custom questions, such as company, role or attendance requirements.
- 3. Receive submissions in the Registration layer. The submission is saved before e-mail verification is completed, so a delayed verification e-mail does not remove the Registration record.
- 4. Review the attendee, Registration Contact, Registered by information and verification state. For a group submission, review each attendee as an individual Registration record.
- 5. Set the appropriate Registration status: New, Approved, Rejected or Waitlist. Do not treat the status as payment confirmation, ticket issuance or entry authorization.
- 6. In Manual mode, select the Approved and eligible attendees and use Add selected to Guest List. QRGATE validates the Event, authorization, status, verification basis, duplicate rules and existing conversion state.
- 7. Confirm the Added to Guest List state and continue with the normal Guest workflow. Send Invitations separately, then use optional RSVP, QR Ticket and validated Check-in where configured.
When Automatic transfer may be appropriate—and its limits
Manual transfer gives organizers a deliberate review point. QRGATE also supports an organizer-enabled Automatic Guest List transfer mode for eligible Registrations. In that mode, the organizer sets the Event policy in advance and the system can move an eligible Registration into Approved status and the Guest List according to the documented verification basis. Automatic transfer still begins with a Registration record and does not allow an arbitrary, unverified public submission to become a Guest.
- Automatic transfer is optional; Manual transfer remains the default.
- Eligibility and backend integrity checks still apply in Automatic mode.
- Automatic transfer does not send Invitations automatically.
- Automatic transfer does not grant Event entry, replace QR Ticket validation or bypass the normal Check-in workflow.
- Automatic waitlisting and automatic Invitation campaigns are not documented QRGATE capabilities.
Operational benefits without overpromising
A controlled event registration approval process can make responsibilities easier to understand because the team has separate states for submission, verification, approval and Guest List conversion. QRGATE’s preserved Registration-to-Guest relationship can also reduce the need to reconstruct how an attendee entered the Event workflow. These benefits follow from keeping the data and transitions in the same Event context; they are not a promise of a specific percentage improvement or a replacement for the organizer’s admission policy.
- Reviewers can work from a Registration list rather than treating every public submission as a Guest.
- Conversion state helps identify attendees who are still Not added and those already Added to Guest List.
- Duplicate conversion protection helps prevent one Registration from creating multiple Guest records.
- The Guest List remains compatible with manually created Guests and supported Excel-imported Guests.
- The workflow keeps Registration, Invitation, RSVP, QR Ticket and Check-in as distinct steps.
Prerequisites and limitations to check before launch
Before publishing a Registration Page, decide whether the Event should use Manual or Automatic transfer and define what verification basis is acceptable for your attendee groups. Confirm the Registration timing, attendee capacity, form questions and any organizer-provided information. Remember that QRGATE’s Registration pricing is informational: the platform can calculate a base price with supported answer or option adjustments, but it is not a payment processor or public ticket sales platform.
- A Registration must belong to the correct Event and pass the applicable verification and eligibility rules.
- Capacity is measured by attendee count, not Registration Group count.
- A Registration QR code points to the Public Registration Page; it is not a QR Ticket or entry credential.
- Guest List transfer locks public Registration editing, so review timing and ownership should be agreed in advance.
- If you need a product behaviour not documented here, contact support@qrgate.org rather than assuming it is available.
よくあるご質問
Does every public event registration immediately become a Guest?
No. A public submission is first saved as an Attendee Registration. In the default Manual mode, the organizer reviews the record and transfers an eligible attendee with Add selected to Guest List. Automatic transfer is an optional organizer-enabled policy for eligible Registrations and still does not allow uncontrolled Guest creation.
How does Manual Guest List transfer work in QRGATE?
The organizer reviews Registration records, updates their statuses where appropriate, selects Approved and eligible attendees and uses Add selected to Guest List. QRGATE checks the Event, organizer authorization, Registration status, verification basis, duplicate rules and existing conversion state before creating and linking the Guest record.
Which Registration statuses can organizers use before Guest List transfer?
QRGATE documents four Registration statuses: New, Approved, Rejected and Waitlist. These statuses support the Registration review workflow. They should not be described as payment approval, ticket issuance or guaranteed admission.
What makes an Event Registration eligible for Guest List transfer?
Eligibility requires a documented verification basis. For self-registration, the attendee verifies their own e-mail. For an attendee added by a group Registration Contact, eligibility can be based on a verified Registration Contact who was authorized to add the attendee. Contact verification does not automatically verify every attendee’s own e-mail.
Can QRGATE automatically transfer eligible Registrations to the Guest List?
Yes, if the organizer enables Automatic Guest List transfer for the Event. The system still creates a Registration first and applies the documented verification, eligibility, duplicate protection and other backend integrity rules. Manual transfer remains the default mode.
Does adding a Registration to the Guest List automatically send an Invitation?
No. Guest List transfer creates the Guest and preserves the Registration relationship, but it does not automatically send an Invitation. The organizer continues with the separate Invitation workflow.
Does Registration approval grant Event entry?
No. Registration and Guest List transfer do not grant Event entry by themselves. After a Guest is created, the normal Guest lifecycle applies: Invitation, optional RSVP, QR Ticket and validated Check-in. A Registration QR code is for reaching the Registration Page, not for entry.
What happens to the Registration record after an attendee is added to the Guest List?
The Registration remains as a historical and relational source, and QRGATE records the Guest relationship and conversion state. Public Registration editing is locked, the attendee is shown as Added to Guest List and the Guest becomes the operational record for the later Invitation, RSVP, QR Ticket and Check-in workflow.
Create a controlled registration approval workflow
Keep public submissions separate from your accepted Guest List, review eligibility clearly and move approved attendees into the Event workflow with an explicit transfer step. Create a QRGATE account and try the demo for your next Event.
Create an account and try the QRGATE demo