Medical conference registration capacity management becomes difficult when one Registration Contact can add several colleagues. A form that counts submissions or groups may show one registration while consuming several attendee places. At the same time, a public “places remaining” figure can become outdated when multiple people submit concurrently. The result is a gap between what the registration page appears to allow and the number of attendees the Event can actually accommodate.
The practical solution is to define capacity in attendee units, keep Registration separate from Guest List admission, and enforce the final decision on the server. QRGATE’s optional Event Registration module supports this model for individual and multi-attendee Registration workflows.
The operational problem: one submission may represent several attendees
A medical conference may accept registrations from individual clinicians, company coordinators, agencies or administrative contacts. In a group workflow, one verified Registration Contact can register multiple attendees for the same Event. Each attendee is a separate Attendee Registration record, even though the people were entered through one group context. This creates a common capacity failure. For example, a Registration Contact may add five colleagues. If the system counts the Registration Group as one unit, the event appears to have used one place when it has actually received five attendee registrations. The same problem can occur when a spreadsheet tracks one row per company or when an organizer informally treats each form submission as one attendee.
- The registration form may count groups or submissions instead of individual attendees.
- A Registration Contact can add several people in one workflow.
- A visible remaining-capacity number may become stale while other submissions are being processed.
- Manual spreadsheets and informal caps do not provide one server-enforced Event capacity.
Why this affects guests and event teams
An incorrect count creates uncertainty for both sides of the registration process. A prospective attendee may see apparent availability but encounter a capacity decision after another group submits. The organizing team may need to reconcile form entries, group members, approval decisions and spreadsheet totals before knowing how many people have actually claimed normal capacity. The operational impact is not limited to the registration page. Overlooking one or more people in a group can affect planning for communications, Guest List transfer, Invitations and later Event entry. It can also create confusion about whether a submitted Registration is already an accepted Guest, whether any externally handled registration fee or payment requirement has been completed, or whether the person is entitled to enter. Those are separate workflow stages and should not be merged into the capacity calculation.
- Guests may receive unclear signals about whether places are still available.
- Organizers may spend time reconciling group records with attendee totals.
- Registration capacity can be confused with approval, Guest List membership or Event admission.
- A capacity decision does not itself create a Guest, QR Ticket or Check-in authorization.
Why common manual workarounds fall short
Several workarounds appear useful but do not solve attendee-based capacity control reliably. A spreadsheet can help a team review registrations, but it is not the final server-side business rule for concurrent public submissions. A manually updated “remaining places” message can also become inaccurate between page load and form submission. Another workaround is to limit the number of Registration Groups. That does not reflect the real unit when each group can contain different numbers of attendees. Asking every person to submit a separate form may simplify counting, but it removes the supported group workflow that companies and coordinators may need and can make it harder to preserve the relationship between the contact and the people they registered. Approval is also not a substitute for capacity enforcement. Approval controls whether an eligible Registration can move through the organizer’s Guest List workflow; it does not change the fact that New attendees use normal capacity.
- Manual spreadsheet totals can lag behind public submissions.
- A front-end availability figure is informative, not the enforcement mechanism.
- Counting groups instead of attendees underestimates multi-person registrations.
- Approval, external payment instructions and admission are separate concerns.
How QRGATE manages capacity by attendee count
QRGATE places capacity in the Event Registration settings alongside Registration opens and Registration closes. The configured maximum is an Event-level maximum attendee capacity. The unit is the attendee, not the Registration Group. For normal capacity, New and Approved attendees occupy places. Rejected and Waitlist attendees do not occupy normal capacity. A saved Registration submission is created before e-mail verification is completed, so a New attendee record can contribute to capacity even while verification is pending. The final capacity check is performed server-side and is designed to handle concurrent submissions. This matters when two or more people submit at nearly the same time: the displayed availability value is not treated as the final authority. The backend applies the capacity rule when processing the submission rather than relying only on a browser display.
- Configure Registration opens, Registration closes and maximum attendee capacity for the Event.
- Count each Attendee Registration, including attendees added by one Registration Contact.
- New and Approved attendees use normal capacity.
- Rejected and Waitlist attendees do not use normal capacity.
- Use the server-side capacity check as the final decision.
The QRGATE modules that work together
Capacity control is part of a wider Event Registration workflow rather than an isolated form setting. The Event is the shared business context. Its Event Registration settings define timing, capacity and optional public availability. The Public Registration Page presents the Event information and Registration Form to prospective attendees. The Registration Form supports individual Registration and, when enabled for the Event, multi-attendee or group Registration. A Registration Contact can add several attendees, while each person remains a separate Attendee Registration record. Registration statuses, verification basis and Guest List conversion state remain visible to the organizer. After the capacity-aware intake stage, the organizer can use Manual Guest List transfer—the default—or enable Automatic Guest List transfer for eligible Registrations. This is where capacity management connects with the Guest List, but the two layers remain distinct. A public submission is first a Registration, not an accepted Guest.
- Event and Event Registration Settings: define the Event context, timing and capacity.
- Public Registration Page and Registration Form: collect individual or group submissions.
- Registration Group, Registration Contact and Attendee Registration: preserve group context while counting people individually.
- Registration statuses and verification: show the current intake state and eligibility basis.
- Guest List transfer: move eligible attendees into the later Guest workflow through Manual or organizer-enabled Automatic transfer.
A practical medical conference capacity workflow
Use the following workflow when setting up a hypothetical medical conference with a fixed attendee limit: 1. Create the Event and enable Event Registration. 2. Set Registration opens and Registration closes for the intended intake period. 3. Enter the maximum attendee capacity in attendee units—for example, the total number of people the Event is configured to accept. 4. Decide whether to enable multi-attendee Registration for company coordinators or other Registration Contacts. 5. Choose whether to show public availability. This can help visitors understand the current position, but it remains informational. 6. Configure any required Registration Form fields or custom questions. 7. Review incoming Attendee Registration records. New and Approved records use normal capacity; Rejected and Waitlist records do not. 8. Use the server-side result as the authoritative capacity decision when submissions occur concurrently. 9. Transfer eligible attendees to the Guest List manually, or use organizer-enabled Automatic transfer where the documented verification basis is satisfied. 10. Continue with the separate Guest workflow: Invitation, optional RSVP, QR Ticket and validated Check-in. This workflow lets the registration team manage intake without treating a form submission as automatic admission.
- Use a hypothetical conference-wide maximum rather than an undocumented session or room limit.
- Keep public availability optional and separate from enforcement.
- Review status and verification information before Guest List transfer.
- Remember that Guest List transfer does not automatically send an Invitation.
Benefits and boundaries to assess before choosing a solution
Attendee-based capacity management gives the organizing team one clearer operating rule: every person in a group contributes to the Event’s attendee total. Server-side enforcement also reduces reliance on a stale browser counter when submissions overlap. Optional public availability can provide useful context without requiring organizers to expose the maximum capacity figure. The model has important boundaries. QRGATE documents Event-level maximum attendee capacity; it does not document separate capacity limits by session, track, ticket type, meal choice or venue room. Waitlist is a supported Registration status, but automatic placement into Waitlist is not documented. QRGATE can display informational registration pricing and external payment instructions when needed, but it does not process attendee ticket purchases or event registration fees. This is separate from the commercial relationship between QRGATE and its own customers, who may purchase QRGATE service packages or credits for use of the platform. Capacity also does not decide approval, Guest List membership or admission. Registration must follow the documented verification and transfer workflow. After a person becomes a Guest, the normal Invitation, optional RSVP, QR Ticket and validated Check-in stages apply. If you need a product behavior not covered by these documented capabilities, contact support@qrgate.org rather than assuming it is available.
- Capacity is measured in attendees, including people added through group Registration.
- Public availability is optional and is not the enforcement mechanism.
- The documented limit is Event-level, not session- or category-level.
- Automatic waitlisting is not a documented QRGATE capability.
- Registration pricing can be informational and external payment instructions can be provided; QRGATE does not process attendee ticket purchases or event registration fees.
- Capacity does not grant admission or automatically create an Invitation.
Frequently asked questions
Does QRGATE count attendees or Registration Groups toward medical conference capacity?
QRGATE counts attendees. A Registration Contact who adds five people uses five attendee places, even though the people belong to one Registration Group. Each person remains a separate Attendee Registration record.
Which Registration statuses use normal attendee capacity?
New and Approved attendees use normal capacity. Rejected and Waitlist attendees do not use normal capacity. Waitlist is a supported status, but automatic placement into Waitlist is not documented.
Can QRGATE check capacity when several people submit at the same time?
Yes. The final capacity check is performed server-side for concurrent submissions. A displayed remaining-capacity value can become stale, so it should not be treated as the enforcement mechanism.
Can organizers show remaining medical conference places on the public Registration Page?
Yes, public availability display is optional. Organizers can use maximum attendee capacity without showing the capacity figures publicly. Any displayed availability remains informative; the server-side check makes the final capacity decision.
Does a submitted Registration consume capacity before e-mail verification?
A Registration submission is saved before the verification e-mail is completed. When the submission creates a New attendee record, that New attendee uses normal capacity. E-mail verification remains a separate eligibility step for the later Guest List workflow.
Does QRGATE automatically place overflow Registrations on a waitlist?
Automatic waitlisting is not documented. Waitlist is a supported Registration status, but the Product Brain does not support claiming that QRGATE automatically moves overflow submissions into Waitlist.
Does reaching registration capacity automatically grant or deny Event admission?
No. Capacity controls Registration intake. A public submission is not automatically a Guest, QR Ticket or admission authorization. Eligible Registrations must follow the configured Manual or organizer-enabled Automatic Guest List transfer workflow, followed by the normal Invitation and validated Check-in process.
Can one Registration Contact register multiple attendees against the same Event capacity?
Yes, when multi-attendee or group Registration is enabled for the Event. A verified Registration Contact can add multiple attendees, and every attendee is counted separately against the Event-level maximum attendee capacity.
Control medical conference capacity by the people you actually need to host
Create a QRGATE account and try the demo to explore attendee-based capacity settings, multi-attendee Registration and the controlled path from public intake to Guest List transfer.
Create a QRGATE account and try the demo