-
A commerce amount field will no longer be allowed to drive registration. A commerce item can still drive registration and the fee control will always drive registration.
-
On a Simple RSVP event the only field that can drive registration is a radio button series.
-
Each guest listed on the event form would be treated in the system as a registrant to that event / activity.
Roles
Here's a brief summary of what's going on with roles:
- Primary registrant role is applied on Registrant step (and all categories and fields that exist on that step)
- Primary registrant role is applied on Guest step (and all fields that exist within the guest category)
- Primary registrant role is applied on regular steps (and all categories and fields that exist on that step)
- Primary registrant role is applied on Activities steps
- visibility of the activities on that step can be determined by the Primary Registrant's role chain and the guest's role chain:
- first radio button: activity visibility will only look at Primary Registrant's role and will allow everyone to attend
- second radio button: activity visibility determined by the Primary Registrant and Guest roles, but only people who match the roles can attend
- third radio button: activity visibility determined by the Primary Registrant and Guest roles combined, so as long as one person meets the role, everyone can attend
- fields that show up within activities will be determined by each registrant's roles
- visibility of the activities on that step can be determined by the Primary Registrant's role chain and the guest's role chain:
Roles are not be applied to the overall fee control or to the fees in the fee control when the admin is in the data entry mode on an event registering on behalf of someone.
Fields in guest category are driven off of Primary Registrant role. Primary Registrant roles are also applied on other steps and other categories. The only place where the guest role applies is activity categories and when the option is used to enable the category to collect main registrant and guest information .
The Registrant step can't be role-based. If the user registering for the event has access to the event form, then they will have access to the registrant step and category.
Registrant step: Audience is NOT available
Registrant step categories: Audience is available.
Guest step: Audience is available.
Guest category: Audience is NOT available.
Activities step: Audience is available.
Activities: Audience is available.
Regular step: Audience is available.
Regular category: Audience is available.
Validators
- If a primary registrant says 'NO' they will not be attending the event on a Simple RSVP Event or they do not enter a value in the field that is driving registration (Fee Control or Commerce Item) on a Fee-Driven Event, they are not allowed to register a guest. A message is displayed and the 'Add Guest' button is disabled.
- If there are no fields on any of the event models that are required, a warning is displayed letting the admin know that in order to prevent someone from submitting a form without filling out any information, fields should be required.
-
If the Primary Registrant doesn't enter a value in the field that is driving registration, they will not be allowed to submit the form. A message will be displayed on the last step of the form when the Primary Registrant tries to submit the form. It would be a best practice to make the fields driving registration required.
-
If a field driving registration is not selected for the Guest, the guest will not be able to be added to the event. A message will be displayed when the Primary Registrant tries to 'Save' the guest and they will not be able to move forward. It would be a best practice to make the fields driving registration required.
- In the messaging that is displayed to the Primary Registrant when a required field is not filled out on the Activity Step, we have added more details to include the Activity Name and the Registrants Name.
Emails
- A Primary Registrant can add a guest and use the same email address for the guest that they used for themselves. These records will not be merged in the nightly process that automatically merges two non-member records with the same email address.
- A Primary Registrant can add multiple guests and use the same email address for every guest. These records will not be merged in the nightly process that automatically merges two non-member records with the same email address.
- If the same email address is used for the Primary Registrant and the guests and the option 'To send guest a confirmation email.' is checked, we will send multiple emails to the same address.
Event Registration Driver
- The registration driver for the main event should always be added to a step before the guest step.
Mis-configured Events
- Messaging has been added to ensure that admins and members are warned in advance if an event is mis-configured. They are not allowed to register for an event that doesn't have a registration driver.
Incomplete Submissions
- The event registration models have been built on form submission, so the event will not be saved until the form is complete and has been successfully submitted.
Member Limits
- If an event member limit is reached, a user is not able to register or add guests for the event and activities even if activity member limits have not been reached. If the admin wants the activity limits to be enforced, then member limits should not be set for the overall event.
- The maximum number of guests that can be added to an event is 19, so the individual member limit can never exceed 20 on an event.
Confirmation emails
- Guests are not globally opt-out of marketing emails, so when sending out marketing emails, it would be best practice to exclude the non-members to ensure the guests do not receive unwanted emails.
- When a guest is removed from a registration through the edit registration process, an email will not be sent to that guest.
Fee Control
- It is a crucially important best practice that customers utilize the Guest Category for collecting guest information, and the Fee Control for collecting registration fees for paid events. These two pieces directly impact the value and validity of Event reporting and exporting.
- A Fee Control, cannot have a commerce item in the same Event or Activity that also drives registration.
Promotion Codes
Event promotion codes can be used on the overall event and will continue to be applied to the total amount charged for the event. The promo code field will only be able to be added to the event one time.
Pre-populate from an email link
- The pre-populate from an email link will be supported on the event registration models. Only the Primary Registrant information will be pre-populated.
- If a member who has already been registered as a guest is sent an email with the pre-populate email link included when they arrive at the event they will receive the 'You have already been registered for this event as a guest' message with a link to resend the guest confirmation email if one was sent during the initial registration.
If an email was not sent to the guest during the initial registration, the 'Resend Confirmation' verbiage will not be included in the messaging.
- If a member who has already been registered as a guest to one event is sent an email to a different event with the pre-populate email link included when they arrive at the event they will be able to register for the new event as the Primary Registrant.
Identity Checkpoint and Non-member merge
- Guests added to the event will create non-member accounts. These guests will not go through the Identity Checkpoint process even if it is turned on for the event. The Primary Registrant will still go through the Identity Checkpoint process if it is enabled.
- The non-member guest records that are created cannot be merged through the non-member merge process. If a guest is included in a non-member merge file, the guest will be ignored.
Mobile Friendly
- The registration flow for an end user is mobile friendly. This includes adding the guests and selecting the guests that will be attending each activity.
Progress Indicator
- A wrapper has been added around the progress indicator with a unique class that could be updated by the iModules Design team to change the look of the progress indicator. Here are the details on the CSS class:
- The wrapping DIV tag now has a style applied called idbmsBreadcrumbWrapper. The existing styles also remain.
- The wrapping DIV tag now has a style applied called idbmsBreadcrumbWrapper. The existing styles also remain.
Miscellaneous Rules
- The scenario that allows users to purchase commerce items for an event without registering, such as a homecoming t-shirt, is not supported.