Registration Templates

As you've already read, templates contain a majority of the Event Registration's configuration. There's a lot to cover, so let's get started. To keep it simple, we'll break the screen down into bite-sized chunks. You can edit registrations under Tools > Event Registration.

Edit Registrations

  1. Template Name - The name of your template.
  2. Active - When a template should not be used anymore you can deactivate it. You could also delete it, but that would also delete all the registrations that use it.
  3. Category - To help organize registrations, you can organize and secure them by category.
  4. Description - You can optionally provide a description for the template.
  5. Group Type / Group Member Role / Group Member Status - These fields help tell Rock what settings to use when it drops the person into a group. In this case they will be placed into the group with the Role of Member and the Status of Active.
  6. Allow Multiple Registrants - Fairly straight forward.
  7. Max Registrants Per Registration - This indicates how many people you can register at one time. This only applies if Allow Multiple Registrants is enabled.
  8. Registrar Options - This option allows the event coordinator to auto-complete the registrar's information with the first registrant's information as well as hide the registration form altogether. This is useful and streamlines the process when the person registering is also the registrar (say, for example when someone is registering themselves for an event). The options for this setting are:
    1. Prompt for Registrar - This default setting displays the standard registration form and process.
    2. Prefill First Registrant - This setting auto-completes the registration with the first registrant's information. This is helpful when the registrants don't log in to register for the event, but you still want to auto-complete their information.
    3. Use First Registrant - This setting also auto-completes the registration with the first registrant's information, but it also hides the registration panel during the Review Registration step of the process unless the form doesn't collect the registrant's email address. In this case, the registration panel will be displayed during the Review Registration step since that information is required for registration communications.
    4. Use Logged In Person - This setting will use the information of the person who is currently logged in to your website. Any information that is known about the registrar will be "locked" and unable to be edited, but any missing information (for instance, if their email address is blank on their record) will be able to be filled in during the Review Registration step, as above.
  9. Registrants In Same Family - Creating the family structures during the registration process can be tricky. This setting allows you to give Rock hints about the people who are registering for the event. If you're hosting a pastors' conference, you'll probably want to enter No since the registrants are most likely not in the same family. Rock will then create new families for each registrant. Yes will assume that all the registrants are in the same family. Ask enables the cool functionality you saw during the walk-thru above. It provides a very elegant way for the registrar to tell you about the family make-up.
  10. Show Family Members - Selecting Yes or Ask on the previous Registrants in same Family option, will enable this setting. Checking Yes here allows people who are logged in to select one of their existing family members for each registrant in a convenient drop down list -- a real time saver for family events. If you choose Ask, the family list will not be available until you indicate that the current registrant is in the same family as the currently logged in person.
  11. Show SMS Opt-in - When enabled a checkbox will be shown next to each mobile phone number allowing the registrar to enable SMS messaging for this number.
  12. Connection Status - If a new person record is created as part of the registration process, this is the Connection Status that will be assigned. Selecting a status here will override the Connection Status setting in the Registration Entry block's settings.
  13. Enable Wait ListChecking this box will enable the wait list functionality. See the Wait Lists chapter below for more details.
  14. Record Source - Used to track where a new individual's info was entered into the system.
  15. Notify - When someone registers for an event, we often can't wait to find out. This setting allows you to notify several different parties.
    1. Registration Contact: This is configured on the registration instance.
    2. Group Followers: The groups that the registration is linked to can be followed by people with view permissions.
    3. Group Leaders: All of the individuals that have roles that are marked Is Leader in the group linked to the registration will receive an email.
  16. Add Person Note - When checked, registrars and registrants will have a note added to their timeline that denotes that they have registered for the event.
  17. Login Required - Requiring the guest to log in ensures that a duplicate record is not created for the registrar, but it does come at the cost of requiring the guest to log in (and possibly register for a login) on your site.
  18. Set Cost On - This setting determines where the cost will be set, on the template where all registration instances will share it, or on each individual instance.
  19. Financial Gateway - The financial gateway you would like the financial transactions to be processed with.
  20. Enable Payment Plans - If you want people to be able to pay for registration costs over time, you can enable this to allow the creation of Payment Plans. We discuss Payment Plans in the Payment Plans chapter.
  21. Batch Prefix - Optional prefix to add to the financial batches. If left blank the prefix from the registration block will be used.
  22. Selectable Payment Frequencies - The payment frequencies available for the Payment Plan.
  23. CostThe cost of the registration.
  24. Minimum Initial Payment - This is the minimum amount that must be paid at the time of registration. Leaving the field blank will have the effect of requiring full payment. A minimum initial payment amount is required to allow partial payments.
  25. Default Payment Amount - This is an optional setting that lets you specify the amount to be filled in by "default" when registering for an event. The amount you configure here will be filled in automatically, but the registrar will have the option of changing the amount down to the Minimum Initial Payment, if they wish. Note: this only works if the Minimum Initial Payment is greater than zero.
  26. Registration Workflow - This setting allows you to set a workflow to be run with each registration. A similar setting exists on the instance if you need a different workflow per instance. Note that the workflow is only launched if the registration is done through the Registration Entry block on the external site. The Registration entity is passed to the workflow.
  27. Registrant Workflow - Here you can specify a workflow to be launched for each registrant within a registration. Both the 'RegistrationRegistrantId' and the 'RegistrationId' will be passed to the workflow. Note that the workflow is only launched if the registration is done through the Registration Entry block on the external site.
  28. Required Signature Document - Here you can set an electronic signature document to be signed for each registration. Currently all signature documents are "in-line" and will appear as their own step within the registration process. You'll want to use Rock's native Electronic Signature Document functionality, as well as the Obsidian version of the Registration Entry block, for this to work.
  29. Allow External Updates to Saved Registrations - This setting keeps individuals from editing a registration once it has been saved. It's common that someone may come back to a registration to make a remaining payment. While there they can change any of the registrant information. Disabling the feature keeps these edits from occurring.
  30. Show Communication Settings - Since the communications settings for a template are rarely changed, we've hidden them from everyday viewing. Select this checkbox to view these settings.

Minimum Due Today and Amount To Pay Today

The Cost and Minimum Initial Payment fields described in the prior section above have a direct impact on the Minimum Due Today and Amount To Pay Today fields seen during the payment stage of the event registration process. Let's take a quick look at how these fields work together.

Let's say that you configure your template (or instance) so that it has a total Cost of $200 and a Minimum Initial Payment of $100. When the person goes to register and pay, they are limited by these settings. The Minimum Due Today field, which comes from the Minimum Initial Payment setting, means exactly what it says. The person will not be able to pay any less than $100 (in our example) no matter what. However, the person can pay more than the minimum. The limit to how much they can pay is the total Cost of $200.

So, in our example, the person can pay any amount between $100 and $200. Whatever amount is chosen would go into the Amount To Pay Today field. If a person in this scenario pays $150 today then they will be making a partial payment and will need to provide the remaining $50 at a later time. They could split that $50 into two $25 payments by making another partial payment.

Electronic Signatures

Let's take a moment to point out a really powerful feature that we glossed over a bit. Rock can automate the process of requiring electronic signatures after each registration. We cover this topic in detail in the Rock Admin Hero Guide.

Build Forms

Now for the fun part - creating the entry form. When you see the power here, you'll have no choice but to smile.

At a minimum you must collect the registrant's first and last name. But in most cases, you'll want to add at least a couple more fields. When adding fields, you have your choice of where and how they're stored. Let's look at the options.

  1. Source - Your selection here drives what you ask on the form for this question, and how it's stored. There are four options:
    1. Person Field: These fields come right off the person's record. They include things like:
      1. Campus
      2. Address
      3. Email
      4. Birthdate
      5. Gender
      6. Marital Status
      7. Phone Numbers
      8. Connection Status
    2. Person Attribute: This type allows you to take what they've entered and place it into a person attribute.
    3. Group Member Attribute: This allows you to store their entered values into a group member attribute of the linked group.
    4. Registrant Attribute: The final type allows you to configure new attributes that will be stored with the registrant.
  2. Internal Field - This setting allows you to define the attribute but keeps it from being displayed on the external registration form. It will be made available however when editing the form internally. This is used for internal fields that will be entered after the registration takes place, or for simply displaying, for example, an existing person attribute on the grid for event-administration purposes.
  3. Common Value - Filling out forms can be tedious. This setting allows you to take the entered value from the first registration and auto-populate the same field for the subsequent registrants. Note that Common Value is only available on the Registration Entry block.
  4. Use Current Value - In an effort to reduce the amount of data that must be entered, this setting takes the current value from the registrar's record. This is especially helpful for attributes like 'Address'.
  5. Required - This simply indicates whether the person must fill out this field before proceeding with the registration.
  6. Show on Grid - This will place this attribute on the grid of registrants. It can be very helpful as long as you limit the number of items you put on the grid.
  7. Show on Wait List - If enabled, this field will also appear for individuals placed on theWait List.
  8. Lock Existing Value - If you enable this setting, the person's record will not be updated to reflect what they enter for this field. How this looks to the person registering can vary (see below).
  9. Pre-HTML / Post-HTML - Like the workflow entry forms, these fields allow you to surround your entry fields with custom HTML markup. With some basic web design knowledge, you can use these fields to create richer experiences.

Lock Existing Value

As noted above, when adding a form field you can choose to Lock Existing Value. This simply means the person's existing record in Rock will not be changed to match what the person enters during the registration process for the given field.

Let's say you enable this feature on the Birthdate field, and Ted Decker is registering his son Noah for camp. Noah has a record in Rock already, with a birthdate of 3/10/2014. If Ted gives a birthdate of 3/11/2014 during the registration process, it will essentially be ignored and Noah's birthdate will remain locked at 3/10/2014.

Enabling Lock Existing Value on a form field will sometimes mean the field can be seen but not changed. In the example pictured below, this applies to the First Name, Last Name, and Birthday fields.

In the image above it's important to note that Ted used the Family Member to Register drop-down, where he selected Noah Decker. This means Rock knows right away who the registration is for, so the fields with Lock Existing Value are not editable.

However, if the registration template is not configured to Show Family Members then Ted won't have that drop-down list to choose from. In that case, the Lock Existing Value fields will be editable so Ted can provide Noah's information manually. But just because they can be edited on the form doesn't mean the Lock Existing Value setting is ignored for these fields. When the registration is submitted and Noah's record is found, his existing data will still be unchanged. The same is true if Show Family Members is enabled, but Ted is registering someone outside of his family, as pictured below.

Just remember that in the example pictured above, Katie's name and birthdate will not be changed if that information is already in Rock. Those fields can be edited during the registration process, but that's only to allow Ted to complete the form for people outside his family. The Lock Existing Value functionality remains in effect.

Add Conditional Fields

In many cases unique information will apply to each registrant. Event registration form fields have conditions that control whether they are shown/hidden based on the registrar’s selection of a prior form field value.

The conditional field options will be different based on the Gender selection.

First, we'll have to add the form field on the event registration template. After creating the field, a filter icon-button will be shown on the forms grid.

Clicking on the ti ti-filter icon on the Form Field List will display the criteria selection for that field.

Note

Limitations on Conditional Fields
You may have noticed in the Forms section above that not every field in our example registration form has the  icon next to it. That's because you can’t apply conditions to every type of field on your form.  
Only attribute fields that use a control which is text, list, checkbox, person picker, or date pickers can have criteria applied. In other words, if you don’t see the ti ti-filter icon then the field type you’re using can’t have conditional logic applied.  

Click Save. Now you can see that the fields with conditional rules have a highlighted filter button.

Use Registration Attributes

While customizing the template for your event, you can add Registration Attributes directly from the same section. This would allow for the collection of attributes about the registration that do not pertain to a specific registrant. Use the ti ti-circle-plus icon to open the attributes page.

  • Template Name - The name of your template.
  • Registration Attributes - Attribute drop down, located on the main template section below the registrant forms.
  • Add Attribute - Clicking on the plus button opens the attribute window to configure attributes for this event template.

Below you can see the Registration Attribute window open. Here you will create the attribute for the event. In the Categories drop down, you can choose to show this attribute at the start or end of the registration. If a category is not selected, the attribute will display at the end of the registration.

Attribute visibility is mainly controlled by security settings. The 'Public' checkbox pictured above acts as an override for situations where a person has rights to view an attribute, but we want to restrict visibility to attributes on public blocks. To hide a registration attribute, update the attribute's security to staff-only.

Great, now in this event template, every instance will have the same attributes on the registration.

To add a "hidden" or "staff-only" registration attribute to your template, create the desired attribute like normal and save the template. Then, edit the template and click the lock icon next to the attribute. Establish the appropriate permissions (i.e., only staff can view/edit) then save the template again. This will hide the attribute from the general public during registration, while allowing staff to view and edit it when managing registration details.

Set Up Registration Emails

Confirmation Email

After completing the registration, you can set up a confirmation email. This email also acts as an emailed receipt. Remember that the below settings are only visible if you enable Show Communication Settings at the bottom of the page under the 'Terms/Text' section.

While you're free to modify this email, we've provided a template that should work in most cases. Below we've shown what this sample email will look like. Note that the highlighted section comes from the Additional Confirmation Details field of the registration instance.

Reminder Email

We all appreciate reminders. Especially for events we may have registered for long ago. On this screen you can edit the reminder emails. When you create the registration instance (discussed next), you will configure when this email will be sent. Like the other communications, these settings are only visible if you enable Show Communication Settings at the bottom of the page under the 'Terms/Text' section.

Again, we’ve provided you with a capable template. One thing to note here is that the template relies on the registration instance's Additional Reminder Details to set when the event will occur. We've highlighted this part in the email below.

Payment Reminder Email

Allowing partial payments is great, but getting the remaining balance has always been difficult. That was until Rock came around. With Rock you have several tools for getting the remaining balance quickly and easily. The configuration items in this section help set up the communication tools for these reminders. For the most part you can leave them as is. You can read more about these tools in the Payment Reminders section below. Remember that the below settings are only visible if you enable Show Communication Settings at the bottom of the page under the 'Terms/Text' section.

Customize Registration Terms

Event registrations can be used for several different kinds of events. To help fit different types of events, we allow you to customize many of the terms used during the registration process. In this section you can also configure the success text that displays on the final page of the registration screen.