A registration type is a named way someone registers for an event, such as "Member," "Non-Member," "Student," or "Exhibitor Staff." You can connect each type to a registration process and one or more registration packages, then limit it to the people who should use it.
Use registration types for the kinds of registrants your event has, such as Member, Non-Member, Student, or Exhibitor Staff. Use registration packages for what those registrants receive, such as a Full Conference Pass, an In Person Attendee pass, or a Monday-only pass. If you set these up the other way around, with registration types named "In Person" or "Virtual Attendee," you work against how Rhythm expects types and packages to be used, which usually causes problems later.
Prerequisites
You need access to the event in the Events Console.
Where to Find It
Go to Setup › Registration › Types for the event. This page shows every registration type for that event.
- Create Registration Type opens a blank form.
- Open a type from the list to edit it.
The Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Name: | Any text | Empty | Required |
| ID: | Suggested in upper case | Suggested from the name and prefixed with the event's identifier | Required. You cannot change it after you save |
| Status: | Active, Inactive | Active | When inactive, the type is removed everywhere it is offered, including staff and Portal lists. Existing registrations that already use the type do not change |
| Registration Process: | The event's processes | Empty | Sets the process registrants of this type follow. A type with no process is never offered on the Portal registration control |
| Registration Category: | Your Rhythm account's active categories | Empty | Groups the type across events for reporting and microsite security policies |
| This type is visible and available for selection in the portal | On, off | On | Keeps the type off the Portal registration form while still allowing staff to register people with it in the Console |
| This registration type should only be available to speakers | On, off | Off; automatically checked when the name contains "speaker" | Limits the type to people with a speaker record for this event |
| This registration type should only be available to guests | On, off | Off; automatically checked when the name contains "guest" | Marks the type as a guest type and keeps it out of the Portal's own registration-type choices |
| This registration type should only be available to exhibitors | On, off | Off | Available only when exhibitors are turned on for the event. Limits the type to listed contacts of an exhibiting organization |
| Exhibitor contact types | Your Rhythm account's exhibitor contact types | Every type | Shown only when the exhibitor restriction is on. Narrows the exhibitor restriction to selected exhibitor contact types |
| Coupon checkbox and coupon list | On, off, plus one or more coupons | Off | Requires a valid code for one of the listed coupons before someone can register with this type |
| Access Restrictions (switch and rule editor) | On, off | Off | Limits the type to contacts who meet the selected eligibility rules |
| Description (displays in portal) | HTML | Empty | Shown to registrants when they choose the type |
Tip
Give each registration type a distinct Name. When several types share the same or similar display name, dropdowns in query and filter builders can show many entries that look alike. In that case, you may need to choose the correct type by its permanent ID instead of its label.
Warning
Deactivating a type is not the same as unchecking This type is visible and available for selection in the portal. Deactivating removes the type everywhere it is offered, including staff pickers and new packages, while existing registrations that already use it do not change. The visibility checkbox only keeps an active type off the Portal registration form, so staff can still use it in the Console and build packages for it.
You can also make registration temporarily unavailable without formally closing it. Hide the registration link from Event Details in the Portal, or switch the relevant registration processes and packages to inactive and back again. Either approach lets you turn registration off and then back on without losing anything already collected. If no registration path is available at all, the Portal shows a fixed message that no registration packages are available, and that message cannot be customized.
A type's own Status is only one part of making it selectable. The type must also be assigned to the registration process the event is currently using, and that process must be open. A type tied to a closed, retired, or inactive process shows as closed, even when the type is active and the person meets every eligibility rule. If you retire a process or bring a new one online, update the Registration Process setting on every type that should use it. Deactivating or replacing the old process does not move its types to the new one for you.
Restricting Who Can Choose a Type
Access Restrictions, the speaker and exhibitor checkboxes, and the coupon gate control which choices the Portal registration control offers to a specific contact. They do not limit staff registering someone in the Console. Staff see every active type with a process, regardless of its restrictions.
The Portal asks a registrant to choose a registration type before it shows the event's own contact form. Because of that order, these restrictions can only use data that already exists, such as membership, organization, or eligibility records. They cannot use information collected later on that event contact form. Registration also does not include a read-only display that simply shows a contact's current membership type and status without filtering by it. These settings control eligibility and pricing, not an informational summary, which can matter when one person registers another and needs to see that person's standing.
Speaker-only types require the contact to already have a speaker record for this event. Add the person as a speaker in the event's Speakers area first. The speaker record is what matters, so the type is not offered until that record exists, even after the person is withdrawn from speaking. Speaker type, such as presenter versus co-author, is not something Access Restrictions or package eligibility can check directly. Only the presence of a speaker record for this event is available as a criterion. If you want a type limited to a specific committee rather than to speakers, leave the speaker-only setting off and use only a committee-membership Access Restriction. Turning both on can keep committee members out when they are not also speakers. Separately, an Access Restriction built around a speaker-related registration category is not automatically limited to speakers of this event. Depending on how the category is configured, someone who qualified as a speaker for a different event can meet it too, so use the speaker-only setting above when the restriction must be specific to this event.
Access Restrictions use Rhythm's eligibility-rule editor to limit a type to contacts who match selected criteria, such as belonging to an organization that meets certain criteria, or a hand-written expression when you need to gate on a specific contact field. Do not rely on a flattened preferred-address expression such as
contact.preferred_address_state == "VA"for that state check. You cannot save Access Restrictions if you turn them on without adding criteria, and the editor supports matching all of the listed criteria or none of them, rather than an "any of these" option. Restricting a type by U.S. state or province is not a built-in option. An expression against a supported contact field is the closest available approach, and which contact fields are reliably supported beyond organization or membership checks is not fully documented, so test any expression-based condition carefully before relying on it. When several people are registered together as a group, Access Restrictions are still evaluated against each individual registrant; there is no separate "group registration" criterion. To let inactive members through, use a membership-status condition such as Members > Status = Inactive rather than a non-member condition. Testing a type's eligibility criteria only checks those criteria. It does not simulate the type's other restrictions, such as the speaker-only or coupon gate, so a passing test does not guarantee the type is fully available to that person. Purchasing eligibility on individual packages is a separate, package-level control. If you want to block every package within a type for the same group of people, an Access Restriction on the type itself is usually simpler. Package-level eligibility fits better when only certain packages within a type need their own rule.Coupon-gated types need at least one coupon listed after you turn on the checkbox. A type gated with no coupon listed saves successfully, but every registrant's code is refused because there is no valid coupon to check against. You can also use a coupon-gated type to control who can start a group registration. Create a dedicated group registration type and package, gate the type with a coupon set to 100% off, and share the code only with the people who should register a group. The coupon prompt has not always appeared when someone starts a group registration directly with that type, even though it appears correctly when an individual registration selects the same type. If you use this pattern, be ready to give the code directly to whoever processes group registrations.
Speaker-only types require the contact to already have a speaker record for this event. Add the person as a speaker in the event's Speakers area first. The speaker record is what matters, so the type is not offered until that record exists, even after the person is withdrawn from speaking. Meeting other Access Restrictions criteria, such as belonging to a particular committee, does not replace that speaker record. Without it, nobody qualifies for a speaker-only type, no matter what else is configured.
Access Restrictions use Rhythm's eligibility-rule editor to limit a type to contacts who match selected criteria, such as belonging to an organization that meets certain criteria or having an address in a specific state. You cannot save Access Restrictions if you turn them on without adding criteria. A contact has to meet every criterion you add, but when one criterion lets you select more than one value, such as several states, matching any one of those selected values is enough. Access Restrictions cannot check whether a contact owes a balance on a different event's registration, so they are not a way to block registration for that reason. They also treat a lapsed or otherwise inactive membership as inactive, not as no membership at all. A criterion aimed at people with no membership history does not include a past member whose membership has lapsed. If former members should qualify for a type too, add a criterion for inactive members alongside the non-member one.
Speaker-only types require the contact to already have a speaker record for this event. Add the person as a speaker in the event's Speakers area first. The speaker record is what matters, so the type is not offered until that record exists, even after the person is withdrawn from speaking.
Access Restrictions use Rhythm's eligibility-rule editor to limit a type to contacts who match selected criteria, such as belonging to an organization that meets certain criteria. You cannot save Access Restrictions if you turn them on without adding criteria. A custom expression that checks a contact's preferred address state needs the nested field path
contact.preferred_address.state, for examplecontact.preferred_address.state == "VA". A flattened name such ascontact.preferred_address_statecan be accepted when you save the rule, but it does not evaluate eligibility the way you expect.Coupon-gated types need at least one coupon listed after you turn on the checkbox. A type gated with no coupon listed saves successfully, but every registrant's code is refused because there is no valid coupon to check against.
Tip
If a member reports that a package's pricing did not behave as expected, check whether Access Restrictions are turned on for that registration type. Without any restriction, a package can show different pricing for members and non-members on its own. After you add eligibility criteria, a person has to meet every one of them, which can interrupt that simpler pricing behavior.
Warning
Rhythm does not offer a registration type setting, like a membership application's type filter, that limits which membership types appear during event registration when a membership purchase is part of the process. Instead, each membership type's own eligibility criteria decide whether that membership type is offered during registration. That membership option comes from an embedded "Interested in Becoming a Member" section on the registration form, and it offers only individual membership types, not organizational ones. Because it is part of the form itself, conditional visibility cannot hide it based on someone's current membership status. If you need to keep it from members, build a separate registration type or package for members with a form that leaves the embedded membership option out, and use purchasing eligibility so that member-only package is visible only to members. Used as intended, the single embedded component should work for both a contact eligible to join and a member due to renew, without adding anything else. If you do not want the option at all for an event, you can remove that section from the registration form.
Dependencies and Precedence
- A registration type can be saved before its intended registration process exists. The Registration Process field stays empty until you create the process and return to assign it. Remember to complete that step, since a type with no process is never offered on the Portal.
- A guest type becomes available to guests only after a registration package's guest options, or the process's own guest settings, names it, or leaves the guest type list blank to allow every guest type. Until you create a Guest registration type with This registration type should only be available to guests turned on and give it at least one guest package, the guest dropdown on the Portal stays empty. If that guest package's conditions do not include the primary registrant's type, the guest option still will not appear for that type. A process can also allow guest registration only when a specific guest package is selected, which can make guest rate options disappear until that process-level rule is corrected. If registrants report that guest registration is not showing even though registration is open, check that guest options are configured on the process or package, not only that a guest type exists.
- To let only one registration type bring a guest, create two registration processes: one with guest registration turned on and a maximum of one guest, and one with no guest option. Give each process its own registration form, and place the Guest Registrations form component only on the guest-enabled form. Assign the guest-enabled process only to the registration type that should be allowed to bring a guest. To keep guests out of a path entirely, use the same pattern in reverse. Give that path its own process with the allowed guest count set to 0 and a form that leaves out the Guest Registrations component.
- More generally, when only some registrants need a different question, document, or path, such as virtual versus in-person attendees, create a separate registration type for each path. Route those types through separate registration processes with separate forms, rather than trying to show or hide one question conditionally within a single shared process.
- The exhibitor contact type list narrows the exhibitor restriction to specific kinds of exhibitor contact. It has no effect unless the exhibitor restriction is on.
- Each registration process uses a specific registration form, and that form controls more than the questions asked. The sample name badge and any waiver shown during registration come from the form attached to the process. To remove a badge or waiver, edit that form, delete the corresponding element, and save. Do not change the type or process itself. If a form is left in test mode, Rhythm shows a yellow light bulb icon and a banner warning that the form in use may not be the one actually assigned. Treat that as a signal to check the process's assigned form before relying on what you see.
- Some form logic needs extra setup to behave as expected. A custom transition error tied to a field's value only stops the registrant when the form also includes a form error component. Without it, the rule can match without ever displaying or blocking anything. The same kind of rule can fail silently if the field also sits inside a field group or is marked required elsewhere on the form. If you need to show or hide part of a form based on the event type and Event Type is not offered as a selectable condition in the rules editor, you can enter an expression by hand against the form's own value object, for example
formValue.eventType === "SPECIAL-EVENTS", comparing against the event type's identifier as a quoted string. For confirmation-email content that should appear only when a registrant makes an affirmative choice, use a field type whose unselected state is blank rather than one where every choice stores a value. That way, the condition can tell a real "no" from an unanswered question.
Change Impact and How to Revert
Changing a type's restrictions or coupon gate takes effect the next time the Portal builds the list of available types. It does not change registrations already made with that type.
Permissions
You need access to the event in the Events Console to create or edit its registration types.
Validation and Errors
- A type needs a name and a valid identifier before you can save it.
- Turning on Access Restrictions with no criteria is refused when you save. For coupons, select at least one coupon after you turn on the gate. If no coupon is listed, the type can save, but registrants' codes are refused.
- If an expected registration type is not shown to a specific person on the Portal, check that person against every restriction on the type: speaker status, exhibitor contact listing, eligibility criteria, and coupon code. Any one of those restrictions can leave the type out of their choices.