Summer Camp Configuration


There are a number of scenarios for using the Other Program Registration module, and each of these scenarios can be very different from one another. This article is one in a series of articles designed to help Sysadmins and Program Managers to think through all the configuration and daily-management workflows that are required for running a program with online registration.

Return to Common Scenarios page to read about other scenarios.

Summer Camps signups for Current Students and the Public (with fees)

In this scenario, Summer Camps program registration is configured to:

  • Consider what grade level the registrant will be entering next year (rather than their current grade level at time of registration)
  • Allow parents to either pay online or indicate that they will pay later
  • Guarantee the registrant’s spot in the class only if payment is received

The sections of this article highlight how to (1) Configure the scenario, (2) Publicize registration, and (3) Manage registrations and enrollment.

1. Configuration

Scenario Configuration

Course Classification: Create the needed classification first, then select the appropriate classification from the “Course Classification” field. The courses included in this summer camp will later be tagged with this classification.

Allow Public Registration: To allow people from outside the school community to register, two fields must be set. Be sure that the “Allow Public Registration” checkbox is checked, and “Public Registration Form” field must also be checked. The Public Registration Form field is what selects the right web form for people without existing user accounts to register prior to selecting classes.

Next Year: This is what tells this registration scenario to treat registrants, and filter their available classes, based on their “Grade Applying For” value instead of their “Current Grade” value.

Allowed Roles: The “Allowed Roles” field configures who (by role) is able to access the form and sign up for classes. Allowed roles in this scenario include Student (role ID 1), Future Students (role ID 7), Future Program Students (role ID 54), and Program Students (role ID 56). In addition, enabling the “Program Student” roles (IDs 54 & 56) is necessary for public registration to function.

Allowed Payment Methods: “Allowed Payment Methods” determines which payment options are available when the user completes registration and has fees to pay. In this scenario, the option selected is “Online & Cash Payment.” The “Online” option allows for integration with Veracross Checkout. If the school wishes to configure online payment, please read more about Veracross Checkoutand talk with your Account Manager. The “Cash” option allows the user to select that they wish to pay later. Depending on school policies, it will be possible to invoice later, or require payment “at the door.”

In this scenario, signing up for the waitlist is also allowed. The registration website displays the number of seats available, as well as the waitlist length. Learn more about waitlists.

Course & Class Configuration

Course-Level Settings:

Select the Course Classification: Courses that are included in the Summer Camp offerings must have the correct Course Classification selected.

Use the “Allow Waitlist” flag to enable waitlist functionality. This field grants the flexibility to allow waitlists for some courses but not others in a given registration scenario.

Class-Level Settings (see screenshot):

Select the Program Enrollment Strategy: Setting this field to “Paid Registrations” means the school must receive payment before the child is enrolled in the class. If the family chooses the option to “Pay Later,” the child will not be enrolled until the Program Managers choose to enroll the child (presumably upon receiving payment).

Select the Program Availability Method: Setting this field to “Paid Registrations” means that the Available Seat numbers and Waitlist numbers will be generated based on who has paid. Those registrants who don’t pay upon signup will not be included in the Available Seats count or be considered for the waitlist.

In addition, be sure to set Max Students, Grade Range, Registration Deadline (if applicable), Class Fee, and Catalog Item on the class.

2. Publicize Signups

Since this scenario needs to be available to both current students, future students, and families in the community, it is necessary to publicize signups separately for each constituent group.

For Public Families: Publish the link for “Public Landing Page” on the school website. The “Public Landing Page” contains three buttons: Browse Catalog, Register, and Login. In order to select Programs, Public families must first Register. The registration webform takes basic information about the registrant (see screenshot).

For Current Families: School can post a link to the Program Registration page in the Veracross Portals. This link will allow for Single Sign On from the Veracross portal directly to the Program Registration household landing page.

3. Managing Registrations

As registrants start signing up for classes, the “Registrations” tab on the class record in Axiom will begin to show various statuses depending on where the family is in the signup process. In this scenario, the Program Enrollment Strategy is set to “Paid Registrations,” which means class enrollment records are only created after payment is received. The following describes various statuses for families who are working through signups:

A. Those who are mid-process

Registrations that are mid-process will have the “Pending Selection,” “Confirmed Selection,” or one of the “Pending Payment” status options. In this scenario, “Confirmed Selection” either means that the registrant hasn’t made it to the payment page yet, or it means that the registrant is on the waitlist (and in that case, the Waitlist Number will be populated). In fact, if a registration record stops at “Confirmed Selection” with no Waitlist Number, that might be an indicator that the registration attempt is stalled and the Program Managers may need to help reset the registration for the user. In that case, see “E” below.

B. Those who pay immediately online

See the screenshot to the right. If the parent pays online immediately after signing up, the registrant is enrolled in the class and is included on the roster. The next user will see the number of available seats decrease by one accordingly. This is the simplest path that registrations will take, but the registration scenario allows for other forms of payment, and the program registration tools allow for management of incomplete registration attempts.

 C. Those who choose to pay later

See screenshot to the right. Because Sheila Abbott’s parent selected “Pay Cash”, her registration is recorded as “Pending Cash Payment.” No class enrollment has been created.

The number of available seats that displays online for the next registrant does not decrease because Janet hasn’t paid yet. If other people register and pay and the class reaches capacity, Sheila will be put on the waitlist.

Once payment is received, the school will update the Fee Paid field to one of the “Paid” values and the Status to now be “Enrolled” for this child. This process will create the class enrollment record for this individual.

D. Managing Waitlists

Refer to the Waitlist Configuration and Management article for more details.
waitlist only queue 1st
Because waitlists are allowed and the waitlist length is being displayed in this scenario, if there are as many Paid Registrations as the Max Students number, the next registrant will see “Wait-List only. Queue: 1st.” When the next person registers, he/she will not be asked to pay immediately, as he/she will be on the waitlist. See the screenshot to the right.

After registrants are added to the waitlist, it will be up to the program managers to follow up with the registrants for payment. After payment is received, registrants can be moved from the waitlist to the class roster by updating the Registration Status to “Enrolled”.

E. Those who stop halfway through and need to change their selections

If Veracross Accounting (VCA) is used at this school, managing charges will be done in conjunction with the school business office.

If Veracross Accounting (VCA) is not used at this school, the Registrations tab allows for program managers to locate the charges that have been created as a result of this partial registration so that program managers can easily delete the charges, reset the registration back to “pending” to track that there was an attempt, but let the user start over. After deleting the charges, the next time this registrant logs in, he or she will see the online registration starting point as a “clean slate”.

F. Those who completed registration and paid online, but later ask to change the registration

Veracross Other Programs Registration does not currently support the ability to reassign registration or payment records from one class to another.

G. Those who completed registration and paid online, but later ask for a full refund

Refunds for online payment will be managed directly through the payment provider. Once a refund is issued, program managers will need to update the registration status to “Withdrawn,” add a note explaining why, and then add a “Withdraw Date” for the class enrollment record for the student. By updating the registration status for these withdrawals, program managers have a full history of the registration attempt.

H. Those who are unable to register online.

Some people may wish to participate in the program but don’t have internet access. In these cases, registration can be added via the registrations tab of the class in Axiom. Adding a registration is an important step for consistency of record-keeping. If the family calls and asks for a registration, they will be sending in their payment at a later time. Therefore, do not enroll the registrant immediately; rather, create the ad hoc registration record for this class, and wait for payment to arrive before enrolling the registrant.

If the school uses VCA, the Business Office will probably want to manually create a charge item for this student’s registration, in case an invoice is required. If the school does not use VCA, or if invoices will not be generated, there is no need to create a charge item.