A registration package is the priced product sold through a registration type, such as “Member / Full Conference” or “Non-Member / One Day.” A registration add-on product is a separate optional item any registrant can buy with registration, such as a T-shirt or parking pass.
Both packages and add-ons have a base price, a member price, and prices for each registration deadline on the event. Only packages include the attendance rules and free inclusions described below. A registrant can have only one package on a single registration, so cancel the registration and register again if they need a different package.
Prerequisites
You need access to the event in the Events Console. Before you create a package, the event needs at least one active registration type. Before you create an add-on, your Rhythm account needs at least one active add-on type.
Where to Find It
- Go to Setup › Registration › Packages for an event’s packages, or Create Registration Package to create one.
- Go to Setup › Registration › Add Ons for the event’s add-on products, or Create Add On Product to create one.
- Add-on types are managed outside the event’s add-on products. In the global Events setup area, go to Registration › Add-On Types to see or manage the full list of types your Rhythm account can use. That list applies across events, while add-on products belong to a specific event.
Registration Package Settings
Rhythm builds a package’s full name from the event, the registration type, and the abbreviated name you enter. If you change the type or abbreviated name, Rhythm rebuilds the full name.
The full name also drives other displayed text. It appears as the registration line on an automatic receipt, and it can appear together with a fee or product name in an invoice description. If you clone an event, the new event’s packages keep the earlier event’s names until you edit them, so update the abbreviated name if you do not want the previous wording to carry over.
When packages or similar choices are numbered, Rhythm can sort them by the leading digit as text instead of by full numeric value. For example, a package named “10” can display right after “1” instead of after “9,” so check the displayed order if the sequence matters.
| Setting | Options | Default | Effect |
|---|---|---|---|
| Registration Type: | The event’s active registration types | Empty | Required. Connects this package to one registration type |
| Business Unit: | Your Rhythm account’s business units | Empty | Required. Sets which business unit invoices this package’s purchases; you cannot change it after saving the package |
| Name (Abbreviated) | Any text | Empty | Required. Appears in dropdowns, while the full name appears on product reports |
| This package is available for purchase in the portal | On, off | On | Shows or hides the package on the public rate schedule and the Portal registration form |
| Hide this package from the online store | On, off | Off | Available only when your Rhythm account’s universal shopping cart is on. Keeps the package out of the online store while still allowing it to be sold through event registration |
| Purchasing Eligibility (switch, rule editor, or expression) | On, off, plus criteria | Off | Limits which contacts may buy this package |
| Special Pricing Logic (switch, rule editor, or expression) | On, off, plus criteria | Off | Gives contacts who match the criteria a different price instead of the package’s standard price |
| This package is limited to only certain days | On, off, plus a day picker | Off | Records which event days the package holder may attend |
| Sessions attendance | All sessions, no optional sessions, or only chosen tracks | All sessions | Records which sessions the package holder may attend |
| Function ticket purchase | Any function, only listed functions, or all except listed functions | Any function | Records which functions the package holder may buy tickets for |
| Price and member price | An amount per currency | Empty | Sets the base price and member price |
| Purchase Limit | A number | Empty | Limits how many times one person may buy this package |
| Deadline Pricing rows | An amount and member amount per deadline | Empty | Appears only when the event uses registration deadlines |
| Include Sessions, Include Tickets, Include Add Ons (switches and rows) | On, off, plus rows | Off | Waives the fee for selected sessions, function tickets, or add-ons, up to the quantity you set for each row |
| Cancellation in the Portal (switch and policy) | On, off, then none, specific date, or relative date | Off | Overrides the event’s self-cancellation policy for this package’s holders. Available only when your Rhythm account’s self-cancellation feature is on |
| Description (displays in portal) | HTML | Empty | Appears to registrants when they choose the package |
Tip
Including sessions, tickets, or add-ons in a package is different from selling registration add-on products. An included item is free with the package because its fee is waived, and the registrant can decline it. A registration add-on product is a separate optional item, with its own price, that anyone registering can choose to buy.
If you want an optional paid extra instead of something free with a specific package, create a registration add-on product rather than including the item. This is the right approach for optional cancellation protection and most other purchasable extras, because registrants choose them and pay for them separately.
Sessions and add-ons are configured in different places. A session’s price is set on its own Fees tab, while an add-on product’s price is set here, on the add-on itself.
Tip
Session availability on a package works at the track level; there is no setting to allow or block one specific session by itself. If you want a package to offer only a handful of sessions instead of every optional session, put those sessions in their own track and set the package’s session attendance to that track. Those sessions are then the only ones shown to that package’s registrants, and they can still work as the package’s included selections.
Warning
Clearing Include Sessions after you have already removed some sessions from the included list has behaved inconsistently. In some cases, the cleared selections are removed for good; in others, they reappear when you turn Include Sessions back on. If session inclusion does not match what you expect after editing this setting, reopen the package and confirm the Included Sessions list before you rely on it.
Warning
The days, session tracks, and function limits recorded on a package are not enforced when a registrant books a session or buys a function ticket. Rhythm does not refuse bookings outside those limits today, so use them as information for staff and reports rather than as enforced restrictions.
Free included items work the same way. They are added regardless of capacity or a waitlist, so an included session or ticket can put a function or session over its stated capacity.
When a package lists functions as excluded, or lists only certain functions as included, Rhythm hides the other functions from that package’s ticket-purchase step during registration. Some registrations have shown an excluded function staying hidden even after the registrant switches to a different package. That was treated as a defect, so re-check function choices if a registrant changes packages mid-registration.
When you turn on Include Sessions for a package, the sessions you choose are added to a registrant’s order by default with the fee waived. The registrant can still decline an included session and remove it from their registration. If the package’s Sessions attendance is set to no optional sessions, that setting stops every session, included or not, from being auto-added or offered during registration. Switch Sessions attendance to all sessions or to specific tracks first if you want included sessions to appear and be pre-selected.
If a member sees non-member pricing on a package they should qualify for, check the eligibility settings on the package’s registration type. A person covered under a group or family membership package that is not included in those settings can be priced as a non-member, even when they hold an active membership.
When a package references a registration type, you may need to update both the type’s Access Restrictions and the package’s own Purchasing Eligibility, because either one can leave a gap the other does not close. If the type’s Access Restrictions already reference the person’s membership package, you do not also need to repeat that membership-package check inside the package’s Advanced Rules & Logic. If eligibility still fails someone it should pass, look at other contact-type values there instead.
To let inactive members register at a non-member rate while active members keep member pricing, set the package’s Purchasing Eligibility to match members with an inactive status. Do not try to reuse the plain non-member package for them. Portal availability for a package can also depend on its registration type’s configuration, separately from the package’s own settings, so check the registration type if a package that looks correct still behaves unexpectedly in the Portal.
Purchasing Eligibility and Special Pricing Logic
Purchasing Eligibility limits which contacts can buy a package. Special Pricing Logic gives contacts who match its criteria a different price instead of the standard one. Both use Rhythm’s rule editor, and both can switch to a custom expression for logic the editor’s drop-downs cannot describe; see Rules and Expressions Explained. A custom expression can test a contact field the rule editor does not offer, such as a preferred address state.
Both tools use fields from the contact’s or organization’s CRM record, not from event registration custom fields. A custom field created under event registration custom fields is not available here, so a question asked only on the registration form cannot directly control package eligibility or special pricing. If you need the registrant’s answer to control eligibility, such as identifying themselves as a speaker or co-author, add the field to a CRM contact form instead. Then turn that contact form on in the registration process and reference the field in Purchasing Eligibility or Special Pricing Logic after the answer is on the contact record.
Purchasing Eligibility offers several ways to describe who qualifies:
- Membership Types limits the package to contacts with selected membership types. A contact whose membership type is not included sees no packages available under that type. Use this option when you need to restrict event registration to active members generally, rather than requiring a membership purchase inside the same registration.
- Chapter Members limits the package to members of selected chapters, chapter types, or both. Use this option, instead of an advanced rule that tests chapter IDs directly, to restrict a package to specific chapters.
- Event Registrations limits the package to contacts who are already registered for a different, specified event.
- Membership Add Ons limits the package to contacts holding selected membership add-ons. The value picker for this field does not reliably return selectable results by name, so build the condition with Contains logic against the add-on’s ID instead, or use an expression.
Purchasing Eligibility and Special Pricing Logic behave differently from the other settings on this page. Staff cannot bypass a package’s eligibility criteria from the Console; the same rules apply whether a registrant buys online or staff register them directly. Eligibility is checked at package selection, after the registrant has already chosen a registration type. If someone picks an eligible type but does not meet a package’s criteria, they can see no packages available for that type and must go back and choose differently.
Other rules on the package, such as its own restrictions or Special Pricing Logic, can combine with eligibility and produce the same result. When a registrant reports no packages available, check every rule on the package, not only Purchasing Eligibility. Eligibility criteria decide who may buy a package, but they do not remove it from the public rate schedule, so a restricted package can still appear on Rates & Deadlines.
You cannot combine member and non-member audiences into one package with an any-match condition. Build two packages instead if you need both audiences. When the package being purchased is a membership, it can still appear as a choice for someone who does not actually qualify. The eligibility check runs again when the order is processed, and an ineligible buyer sees the refusal on checkout or the order details page rather than earlier in the flow.
Instead of creating a separate restricted registration type for a benefit only some people should get, attach a restricted package to a general registration type and let Purchasing Eligibility control who can select it. Using separate packages with Purchasing Eligibility, instead of Special Pricing Logic, is also a way to keep tiered prices visible to Portal visitors while still restricting who can buy each tier. If you use this approach, review the related G/L account setup for each package.
For example, a student-only $0 rate is best built as its own package priced at zero and restricted to students. Do not expect one shared package to show different prices to different audiences, because the public pricing display reflects the package’s own price.
A registration package can be purchased only once per registration. If someone might want to add more attendance later, such as an extra event day, model that with sessions inside one package rather than expecting them to buy a second package registration. For an event with many possible attendance combinations, such as a multi-track conference where people mix and match days, sessions, and add-ons, model each real combination as its own package. Do not expect one package to calculate price from day-by-day choices; a package limited to certain days offers a fixed set of days, not a price that recalculates from the days a registrant picks. Cloning a previous year’s event and adjusting its packages is a practical starting point for an event like this.
Rhythm does not stop someone from selecting a group-labelled package or attendee type just because they are registering alone. If the package is otherwise eligible for them, a single registrant can still choose it. For cleaner attendee tracking and reporting, model guest attendance as its own guest package under a guest registration type rather than only as a function. Whether the guest option appears during registration also depends on selecting a package that allows guests, since guest availability is controlled at the package level. Rhythm does not currently offer a way to limit which packages a presenter can select; a presenter can access every registration package, the same as any other registrant.
A package’s product setup can bundle another product into it, such as a membership. A bundled product’s price is set separately from the package’s own price, so you can price a bundled membership at $0 for both member and non-member rates while the registration package keeps its own separate price. If you enter a member price on the bundled product, enter the matching member price on the package’s own pricing too, or leave both blank. Using a member price in one place and not the other can cause configuration errors.
A bundled product’s price does not change with the package’s own deadline pricing. Whatever price you set on the bundled product stays the same through every deadline, even while early-bird and other tiers change the price of the package around it. If your event already sells separate member and non-member packages, leave any additional package-related pricing field blank unless you actually need it. Populating one when packages are already split by membership can add a second, grayed-out price beside the package’s own price on the registration page.
Deadline-based pricing, such as early-bird, regular, and onsite rates, must be turned on in the event’s registration settings before deadline rows appear on a package or add-on. Configure an Onsite tier only when the day-of-event price should differ from the package’s regular price. If onsite registrants should pay the regular rate, leave the Onsite row blank and let it fall back to the base price.
If you need different early-bird and regular pricing for one attendee category that Special Pricing Logic cannot describe directly, create a separate package for that category and price its deadlines independently. Do not try to date-gate special pricing on a shared package. If an active early-bird price is not displaying correctly during package selection, try entering the same amount into the package’s Member Price fields rather than leaving them blank. Populating member pricing has been reported to correct the display in that situation.
A package’s Business Unit sets which business unit’s currencies and accounting apply to it, and you cannot change it after the package is saved. If a package needs a different business unit going forward, create a new package instead of editing the existing one. For a Portal order, the invoice follows the business unit of the registration package that was purchased, not necessarily the event’s own business unit. If registrations are posting to the wrong business unit, check the package, not just the event.
In some setups, the Business Unit field is fixed rather than editable directly on the package because it follows the underlying product configuration. A package’s financial setup can also allocate revenue across more than one G/L account. If a report against a single revenue account looks lower than the event’s total registration revenue, check whether some package components post to a different account.
Registration Add-On Product Settings
Add-On Types are not created here. Set them up once in your Rhythm account’s global Meetings & Shows setup area under Registration › Add-On Types. The types you create there are available to every event, and you choose from them when you create an add-on inside a specific event.
Rhythm creates and manages registration add-on products from the event at Setup › Registration › Add Ons, using an Add On Type chosen from your Rhythm account’s active add-on types. Some add-on products can also be opened and edited from the underlying product record directly, not only through the event’s Add Ons list.
| Setting | Options | Default | Effect |
|---|---|---|---|
| Add On Type: | Your Rhythm account’s active add-on types | Empty | Classifies the add-on |
| Business Unit: | Your Rhythm account’s business units | Empty | Required. Sets which business unit invoices this add-on’s purchases |
| Name (Abbreviated) | Any text | Empty | Required. Appears in dropdowns, while the full name appears on product reports |
| Price and member price | An amount per currency | Empty | Sets the base price and member price |
| Purchase Limit | A number | Empty | Limits how many of this add-on one order may include |
| Deadline Pricing rows | An amount and member amount per deadline | Empty | Appears only when the event uses registration deadlines |
| Description (displays in portal) | HTML | Empty | Appears to registrants when they choose the add-on |
Configuring an add-on on the event is not enough by itself. Registrants will not see it during registration unless the event’s registration form also includes the Choose Add Ons component and the form has been saved with that component in place.
Adding Choose Add Ons to an event’s edit registration form makes the add-on available there too, including in the microsite attendees use to modify an existing registration. The Console and Portal edit flows share the same form. An add-on’s visibility can also depend on configuration beyond its own record, such as the registration type in use and whether the add-on is hidden from the portal, so check those settings too if an add-on is not appearing where you expect.
An add-on cannot be restricted to specific registration packages or registration types. Any registrant can buy it, regardless of which package or type they chose. There is also no way to require a registrant to choose exactly one option among several related add-ons, so expect registrants to be able to select more than one unless you build in a workaround, such as a custom field with conditional logic. Buying an add-on does not create a session registration and does not place any session it might represent onto the registrant’s schedule. If an add-on stands in for a session, the session itself will not show as attended just because the add-on was purchased.
An add-on product does not include built-in variant selection, such as size or color, the way a store product with variants does. For merchandise that needs an option like this, keep the merchandise as an add-on for billing. Then create registration custom fields for the option values, such as size and color, and place those fields on the registration form so registrants can specify what they want.
An inventory or merchandise product used as an add-on shares its shipping configuration, inventory counts, variants, modifiers, COGS, and financial setup with the same product in your online store. Rhythm does not currently offer separate no-shipping treatment for an add-on picked up at the event versus the same product sold through the store.
An add-on that bundles course fees from Certifications applies those fees to the event registration and adds the add-on to the record, but it does not create a registration on the related course offering. The course fee is billed without a matching course-offering registration being created automatically. If you sell an all-access bundle add-on alongside individual courses and want to stop registrants from also buying courses separately after choosing the bundle, add a custom field tied to the bundle choice and use conditional form logic to hide or skip the course-selection step when that bundle is selected.
Dependencies and Precedence
- A package’s function limit only records which functions its holder may buy tickets for. If you need to limit how many tickets one registrant may buy for a function, set that on the function itself in Functions, not here.
- Deadline pricing rows come from the event’s registration settings and use the same deadlines as function fees. Rhythm prices a registration by the date it is processed. It uses the tier for the most recently passed deadline, falls back to the base price when a deadline’s price is empty, and also uses the base price for a registration processed after every deadline has passed. The base member price applies the same way to a member who registers outside every deadline tier.
- The public rate schedule shows one column for each registration deadline, plus a final column for the base price. That final column is generated automatically from the registration process and the package’s own price, is labelled Regular unless your site builder renamed it, and cannot be removed. A separately configured “Regular Registration” column is different: it is an ordinary deadline column you added yourself, and you can remove it like any other if you want only the generated price shown. If the schedule looks like it has a duplicate “regular” price for another reason, check whether the event has two registration deadlines with similar names or overlapping dates, because each configured deadline gets its own column. Portal visibility settings also interact with this schedule. Hiding a registration type from the portal, or turning off a package’s own portal availability, keeps that type or package from being selected during registration, but the package can still appear on the pricing page if only the type, not the package, was hidden.
- Coupons and the registration process they are tied to do not change this form. The package’s own price applies no matter which process the registrant uses to buy it.
- Purchase Limit blocks the same person from buying beyond the number you set, and you can raise or remove the limit later from the package’s or add-on’s edit screen. It counts purchases or orders, not individual registrants, so a single group registration that adds several attendees under one purchase can still push your total attendee count past the number you intended. It also does not create a total inventory cap across every registrant, because it works on the one purchaser rather than the whole event. If you need a hard cap on total registrations, set the event’s capacity in Event Details instead of relying on a package’s or add-on’s Purchase Limit. For an add-on with limited planned supply, deactivate it once enough has sold to stop further purchases, since Rhythm does not offer a built-in event-wide inventory limit for add-on products. Rhythm also does not provide a way to cap how many people from the same organization can buy one specific package.
- Other configuration that references a package or an add-on usually reads its identifier, not its display name. A registration form’s page transition rules, and a custom field’s conditional visibility tied to a specific package, read the Package value as the package’s ID. Build those conditions with an equals comparison against the ID rather than matching on the package’s name. A custom field’s conditional visibility also cannot simply trigger on the fact that some package was selected, so build the condition against the specific package IDs you want to match. A field group’s own conditional visibility works differently: it can test the form’s Package field with a text match, such as package name contains a keyword, which is a workable way to show an extra field group only for certain kinds of package. A condition on Add Ons form data should test the actual quantity, such as an expression like
add_ons[0].quantity > 0, rather than checking whether the field is blank or not blank, because the add_ons array can still contain an entry even when someone chose a quantity of zero. A package’s and an add-on’s identifiers exist only after the event has registration set up. If you need to reference a package or type ID from an event with no registration configured yet, clone an event that already has registration set up instead. - An event integration, such as Zoom, needs certain contact fields to create a registrant on its side. Different registration paths, packages, or forms can collect different fields. A path that omits a field the integration needs, such as one used only for a specific speaker or non-member flow, can fail to create the integration record even while another path for the same event works. If an integration fails for one kind of registrant but not another, compare what each path’s package and form actually collect.
- An event added as a bundled product inside a package behaves differently depending on how you bundle it. A regular bundled product creates a registration for the bundled event automatically. An event added as an inline bundled product appears on the order and its revenue is recognized, but Rhythm does not create a registration record for it. If you need the bundled event to register the person automatically, bundle it as a regular product instead of inline. Even with regular bundling, a bundled or add-on registration can occasionally create more than one downstream registration for the same included item, multiply a ticket selection, or skip creating a registration for one included event, even while the invoice looks correct. If attendance looks wrong, check each included event’s own registration list rather than relying on the order alone. Some bundled setups intentionally preserve revenue allocation across included events by having staff complete some included registrations by hand rather than automatically. If that is how your event is set up, what looks like a missing or duplicate registration may be expected, so confirm the intended design before treating it as an error. Review a live package’s included tickets, sessions, and add-ons carefully before changing them once the event is open for registration, since a registration created before the change can behave differently from one created after it, especially if you later modify that older registration.
- When a registrant buys a membership as part of event registration and that membership package requires a chapter, they must choose a chapter before they can continue. The requirement carries into the embedded membership step the same way it would on a standalone membership purchase.
Change Impact and How to Revert
- Changing a package’s price only affects orders placed after the change.
- Deactivating a package stops it from appearing anywhere it is offered, without removing the package or any registrations that already hold it. If it was the registration type’s only package, that type also drops off the rate schedule because there is nothing left to price.
- Turning off This package is available for purchase in the portal removes the package from the Portal registration form and the public rate schedule, while staff can still register people with it in the Console. Use this when you need to close online registration for badge preparation or on-site processing while staff keep working, or when you want certain packages available only to staff. Eligibility criteria work differently: they can block who is able to buy a package during registration without removing the package from the public rate schedule.
Tip
When staff can register someone for a function ticket, session, or add-on in the Console but registrants do not see the option on the Portal form, check the related settings. Confirm whether the item is included in a package that appears in the portal, whether it is tied to a registration process open for online registration, and whether the item itself is hidden from the portal.
If you need an option that only staff should use, such as a package that tracks a special rate or registers someone for a function only, create an additional registration package for staff use and turn off its portal availability. That keeps it off the Portal registration form and rate schedule while leaving it available for staff to select in the Console.
Permissions
You need access to the event in the Events Console to create, edit, or delete its packages and add-on products.
Validation and Errors
A package needs a registration type, an abbreviated name, and a business unit before you can save it.
A package cannot include the same function fee twice across its included-tickets rows. If you save with a duplicate, Rhythm refuses the save and tells you duplicate function fees were found.
If you turn on certain days, specific session tracks, restricted functions, or any included-items switch, you must add at least one entry before you save.
If saving a package returns an error that Special Prices does not contain a valid value, even though special pricing looks correct, reopen and re-save the special pricing entry. Then save the package again. This has cleared the validation error in observed cases.
If you turn on certain days, specific session tracks, restricted functions, or any included-items switch, you must add at least one entry before you save. The same applies to Advanced Rules & Logic, if your package form offers it. Leaving that option checked with no condition entered blocks the save, so either add at least one condition or turn the option back off.
If a package or add-on is missing from the registration options a registrant sees, check the package’s own configuration first. Confirm its registration type, portal availability, and whether it is tied to an open process before you look elsewhere.
A “No packages available” message during registration means the registrant does not meet any package’s eligibility for that event, whether they are registering themselves in the Portal or staff are registering them from the Console. Check the eligibility settings on the event’s registration types before assuming something is broken.
Saving a package’s financial configuration can fail with a validation error about Deferral Relative Dates, even when deferred revenue recognition is set to defer automatically to the event’s end date and no relative date fields should be required. Treat this as a known issue rather than a sign your setup is wrong, and contact Support if it blocks your save.
A package that bundles another product can refuse to save with a Special Prices validation error when the bundled product’s price, or its member price, is entered as a whole number. Enter the price with two decimal places, such as 660.00 instead of 660, on every affected field. The displayed value may return to whole-number formatting after you save, so you may need to re-enter the decimal places the next time you edit the package.
If a package with a special pricing rule fails to save with a different Special Prices error, open the special pricing rule itself, save it, and then save the package again. This two-step save has been reported to clear the error.
If Save on a package spins without completing or failing, check whether Advanced Rules & Logic is turned on with no conditions added yet. Add at least one condition, or turn the setting off, before saving again.
If the Advanced Rules & Logic picker for Special Pricing Logic will not open or will not let you search, scroll the page so there is more space below the field, then try again.
Package criteria that use a multi-select picklist field with the equals operator keep every value you selected after you save and reopen the package.
After you save and reopen an add-on product for editing, its identifier can display incorrectly as the selected business unit’s name followed by dashes, and other add-ons can appear to show that same value when opened. The add-on’s real identifier is unaffected; hover over the hashtag next to the product’s name to see and copy it.
If a package or add-on is missing from the registration options a registrant sees, even though staff can register someone for it in the Console, start by checking the package’s own configuration: its registration type, portal availability, and whether it is tied to an open process. The Console does not enforce the same portal-visibility filtering the registration form does, so staff being able to add something there does not mean a registrant can select it too.