Event Setup

Key Terms

An event is a basket for one or more activities. Registrants sign up to participate in an activity -- and in so doing are considered participants in the overall event. This is key: what you'll be looking at for reporting purposes more often than not is a list of activity registrants not event registrants. The event holds a lot of configuration (landing page content, registration period, accounting configuration, confirmation email, and more as you'll soon discover) - activities are much more focused on what people will actually participate in.

If the situation warrants (which is rare, admittedly), an activity can also be subdivided into multiple sections which are time (and cap-limited) slices of the activity's scope. A section is one instance of a tour - say you're running them at 10, 10:30, and 11 am and have a max of 40 people on each, you'd set up three sections so they would fill up safely.

A reservation contains one or more people, the first in each reservation (sometimes referred to as a party) is called the primary registrant.

Registrants become attendees once they have been checked in to at least one activity related to the event.

Event Setup

Creating an Event

This process will guide you through creating the event and point you toward docs on activity configuration (since you can't have an event without at least one activity). This is the bare minimum necessary to set up a registerable event.

Admin > Events > Event Setup, then in the upper right click New Event

The event edit screen is organized into 10 approximately sensible sections.

Essentials - key dates and contact information
Location - where we're hosting this program
Look and Feel - landing page hero image and content
Visibility and Access - is this public or is it restricted to a certain audience?
Registration Experience - express registration on/off, field choices, and top-level audience shaping settings
Blurbs - for those who feel extra instructions are necessary, we've left you space to provide them
Confirmation - who's sending it, and the content for the screen and via email (they can be different for good reason!)
Payments and Accounting - how payments are collected and how we account for them in the general ledger
Event Calendar - for organizations who use this data to paint a calendar on third party sites
Miscellaneous - we all have a junk drawer for things that don't fit neatly elsewhere

Essentials

Event name is self explanatory and quite obviously required. Time zone is also required so we know when to begin and end the registration period.

** Time Zone Considerations**

Selecting the baseline time zone for the event is also required, and deserves a brief moment of consideration:

if the event is in person, then set the time zone to wherever the event is happening.
if the event is virtual, unless it's targeted at folks in an alternate time zone, we recommend using the campus time zone.
if the event has a mix of activities on different dates in different locations (including some virtual), it's generally easiest for the staff to manage the event in campus time.

The time zone pick is an important one because (a) it determines exactly when public registration will begin and end and (b) it serves as the default time zone for all activities and fees. We repeat: it's the default and can be overridden at the activity or fee level if and when necessary.

You may have noticed that the time zone defaults to campus time. Pre-COVID this made the most sense; we hope it still does post-COVID too.

Categories, subcategories, and tags are used for reporting purposes. Generally speaking, the category reflects an organizational unit responsible for the event. One or more subcategories are attached to help define a countable descriptor for the nature of the event. Tags further describe it using a more flexible (add-as-you-go) term that helps us drill down on event performance and analytics. Choose wisely!

Location

Every event happens somewhere, even if it's online. Hence the Locale setting - which imposes an in person geolocation for the event (and a default for all activities) or triggers the collection of virtual platform information.

Virtual platform configuration is done at the activity level. This allows you to set up (for example) a series of webinars spanning four weeks in four different time zones and connected to four separate Zoom webinar configurations. Super helpful for segmenting and tracking attendance individually and collectively!

But really, though, by attaching the webinar config to the activity you gain a pile of flexibility you'd not otherwise have.

For in person events, we encourage you to always use the "find location" tab first.

Click the Search button to show a text field.
As you type the name of a location, a list of options will appear below the search field.
Select the location you want from that list. Keep typing to narrow the list.
The information will automatically populate in the area below.
At the very bottom, the Edit this location button will take you to the location setup module and allow you to edit the location if any of the information needs updating.

Didn't find the location you were looking for? That happens! Flip on over to the Create New Location tab.

populate the name (at minimum) and as much address information as you can
AlumnIQ will attempt to determine the geo coordinates of the location from the address (this is used for mapping in the confirmation content)
if the map pin doesn't land exactly where you want it to go, you can always use the Locations menu item to tweak the geo coordinates

Look and Feel

Event appearance is an expansive enough topic to necessitate its own page! Check out event skinning docs here.

Visibility and Access

** 9 times out of 10 ** you'll touch very little in this section. But that other 1 time out of 10 you'll be happy this exists.

Marketing site if you're hosting the primary content about the event on another site, pop the full url in here. We'll include it in a few spots for the registrant's convenience.
Short URL is one of the nice human-friendly features of AlumnIQ. Ever try to read a link to a site over the phone or needed a pretty registration link to publish (on paper or in electrons)? This is where you get that done. The short url you specify (which should be SHORT, SPECIFIC, SWEET, and SENSIBLE) will be stuck on the end of a link that looks like https://{YOUR_ALUMNIQ_DOMAIN}/go/{SHORTURLHERE} - to look something like https://iqu.alumniq.com/go/reunion20 or https://iqu.alumniq.com/go/spring20board. Following that will bring the registrant to the landing page for the event.
Publicly Visible sometimes you want an event to be registerable but not easily discoverable by the general public/unwashed masses. Those situations are generally board meetings, small-format donor meetups, or internal training sessions. In those cases, much like with short URLs, you set the event to "private" and specify the tail piece of the url that is used as the token to get to the registration page. An example would be https://iqu.alumniq.com/attend/secret/alumniboardalumni where 'alumniboardalumni' is the private url key. Much like the key you hide under a rock near your back door, a trusted circle of people will know it's there and can use it to gain access. Not secure - just hidden. If you need secure, see the next section.

Registration Experience

Buckle up because this section has a lot going for it! In here you'll configure who's allowed to register and what you'll be asking of them when you do.

First up, though, is a setting that will enable the simplest and fastest registration flow: Express Registration which is so cool it has an entire set of documentation written about it. We strongly encourage you to read up on it and better yet use it! We advise leaving this enabled as frequently as possible.

Require Authentication

You may optionally Require Authentication to register for an event. When required, users must have an account to register.
If your event requires authentication, you may also optionally Require Affiliation. Leave these checkboxes blank to allow anyone with an account to register. If you check any of these boxes, users must have at least one of the affiliations that you select in order to register.
You may also opt to control registration access with a list. That topic is discussed in more detail in Event ACLs.

List restrictions will act as a gate on the primary registrant only; guests will be allowed per the max guests settings and are not screened against the list.

Requiring authentication is extremely rarely done because it's a significant hurdle to registration for most people. Think long and hard about who you're discouraging (not simply disallowing) by turning this feature on.

Collect Addresses?

Sometimes you'll be hosting a free event that doesn't solicit a gift and you've invited people for whom you already have a known good address. If that's the case, and you want a simple and fast registration experience, you can turn off address collection.

This setting is automatically overridden if (a) any balance is due on the registration and online payment is enabled (we can't process a credit card without a billing address) or (b) a gift is made on a free event, thus necessitating the activation of billing address collectino.

Field Collection

Also in pursuit of a simple/fast registration process, you have the ability to exclude or make optional several bio fields. These were chosen to be non-impactful for fee targeting so you've got a little flexibility in what you choose to collect as a result. Optional = presented to the registrant but not required to be completed. Required = visible and a response must be provided.

Members Only Events

This feature was activated at the end of January 2022

Have an event that is intended to be for members (and their guests) only? AlumnIQ supports validating this at the time of registration.

If you check the box to make an event exclusive, here's what happens:

on the primary registrant's bio screen, they'll be prompted to enter their member number
the member number AND last name on the membership must match what the registrant has input
then and only then will we allow them to continue with registration

Valid member numbers include:

the member number in the membership warehouse feeds you send to AlumnIQ
the temporary member number issued by AlumnIQ at the time of membership purchase (so we can immediately activate and deliver member benefits)

Guests are not subject to membership validation; the primary registrant, once validated as a recognized active member, can invite as many guests as they wish up to the limit set in "Max guests per person" for this event.

Other fields

Max guests per person on the rare occasion you want to cap parties to a certain size, specify it here. Blank is unlimited; any other value excludes the primary registrant.
21+, when checked, shows a banner on the party collection screen indicating that the underage are not generally welcome at this event.
Age of Majority allows you to set the local minimum age to be considered an adult. This is used to validate the age input on the registration form for children/minors. Note that this does not have an effect on fee pricing, which has its own age bracketing system. System default is 18 years old. If your campus-local age of majority is different you may create a ticket and ask us to change this to the sensible default for you. New events will use your default unless they are changed, and this field is where you can alter it to fit the local expectations for events happening away from campus.
Show Who's Coming, when enabled, also lets you establish a registration floor that has to be surpassed for the list to be visible. Showing a small or scarce who's coming list isn't a boost to your promotional efforts so this helps you set it and forget it.
Capture dietary needs adds checkbox (and an 'other' option) to the bio forms for each registrant individually and drives the inclusion of those responses in the event and activity reports.
Allow profile creation for schools not using SSO and autoprovisioned accounts, we'll use the collected registration information for the primary registrant to seed and activate an AlumnIQ login profile on behalf of the primary registrant. This account allows them to update their contact information among other things like access the alumni directory and participate in volunteer programming (both subject to access permissions). That aside, there may be situations where you don't want to make this available to your registrants so you can selectively turn it off as needed.

Associated Students

You'll only want to activate this if you're handling registration for a student sendoff-type event. We've added this so you can draw connections between parents/siblings and (incoming) students who you typically don't have entity records for yet -- but want to recognize that information on a name tag.

Configuration is just like any other optional registration field, with one exception: we obviously can't make capture required.

When activated, the registration form changes slightly. The primary registrant will be prompted to provide info on their related student(s) -- and the level of detail is determined by how much you want to collect. At minimum we require a class year. Whether you also want to collect a school (for our larger customers) or name (generally a good idea) is set on the event config.

Why wouldn't we want to collect a name? Because remember adding an associated student is not registering them. And people don't grasp that distinction -- so in some cases you may only care about the year and/or school, and the name is irrelevant, so you opt to punt on gathering the name to avoid the problem altogether. Generally speaking it's a better idea to capture them so you can update your records accordingly.

Nevertheless, with this feature active we'll capture both their relationship to the student(s) and their class years (plus name and/or school if so configured). If your institution is home to multiple schools, the dropdown for schools will appear. The absolute bare minimum for capture is a class year -- name and school are optional.

Rules:

If the primary registrant is a current/incoming student, they are not permitted to add guests. This is due to the way we attach these associated student records to the party - the primary registrant is our point of reference.
If a guest in the party is a current/incoming student, that guest will not see the "relationship to student" dropdown

All other non-student guests in the party will only need to indicate their relationship to the student(s):

The remainder of the registration process proceeds as normal.

Administratively you can add/remove students as needed. Replace invalid students rather than editing. And on each person's bio form you can adjust the relationship to student value with any necessary reference (not limited to the four options presented for public registration).

Reporting is basic. For the time being, this information is included only in the event attendance report (when exported to Excel) under two columns: relatedStudents and relatedStudentsFull. The former will be a delimited list of year and school associations; the latter includes the student names. Both are compiled for your convenience and easy parsing if necessary.

Blurbs

Higher ed culture is anything but concise when it comes to language. And while we like to think the registration flow is largely self explanatory, we know you'll encounter people either need more explicit guidance (or colleagues who feel they do).

The registration flow is: landing page, bio entry, party, (add guests via repeat bio visits as needed), activity/product selection (for each registrant individually), invoice, confirmation.

On most of those screens you can drop in more copy if/as needed.

We've also made the "make a gift" blurb space on the invoice screen editable should you need to position the ask a certain way for the event.

Confirmation

As the takeaway from the registration process (frequently involving the transfer of payment), the confirmation is really important.

Email Theme controls what your confirmation emails look like. Your department or team may have a standard template that you use; or a special template may have been developed for your event — this is something that we will work together on, but the direction of which template to choose will not come from this documentation.
Email Sender Name if you want the confirmation email sender to be named something other than the default.
Email Sender Address will be the address that the registration confirmation email will be sent from. This does not (repeat not) need to be a monitored or real address so long as the domain matches the rule shown under the field.
Email Reply To Name name of person or department responsible for event management.
Email Reply To Address will be the address that any replies to this confirmation message will go to - be sure this is real and watched!
CC Confirmations to is a list of comma-separated email addresses you want CC'd on all confirmation emails. This is, of course, optional but we know that for some events it's important that you see who's registering as it happens (or you just want to know it's working).
You may also provide a Confirmation Screen Note, which is a message that is displayed after the attendee has completed their registration. If you provide a Confirmation Email Note, it will replace the Confirmation Screen Note in the confirmation email; otherwise the Confirmation Screen Note will also be sent in the email. These are separate because the registrant will typically only see the confirmation note once, but go back and revisit the email several times between registration and attendance. Both of these fields are optional but STRONGLY recommended.

** The Confirmation Email **

The conf email has your confirmation blurb, a rolled-up agenda for the party, and a link to the online confirmation containing links to 'add to calendar' for each party member.

For virtual events, the confirmation email contains "+ Join Event" permalinks that will allow the registrant to join your virutal programs in a reliable, click-tracked fashion

Payments and Accounting

AlumnIQ is pretty darn flexible when it comes to handling event finances. We use your payment gateways to handle the transfer of real dollars, and then defer to our internal ledger to handle the distribution of those dollars across one or more virtual accounts per the event and activity configuration. Our internal ledger is what yields the balance sheet - the one report you need post-event to determine how much money should be GL'd where once all balances are settled.

You'll see this split between real money and internal money pop up time and again in the customer service section where we'll require an account to be selected for the application of a discount or fee (for example), followed by the capture of a supplemental payment or processing of a refund. Our books have to balance and based on the state of those we'll enable or disallow those actual hard money transactions to happen.

All of this is to say: it starts in this section. Setting a default account is the base account used for ledger entries related to this event. You can set different accounts on each activity if/as needed (usually in situations when you're hosting activities with another department under the same event and each deserve a particular slice of the revenues). Choose wisely: once registration opens you will not be permitted to change this setting.

On rare occasions you'll opt to not enable online payment; this is for situations where registration may cost money but all payment is to be made via cash or check on site or through a third party (like a local club or other departmental host). If that's the case you'll be prompted to provide payment instructions which will be shown on the invoice.

In most cases, though, you'll activate online payment and need to specify payment gateways. The payment gateways for registration and gift receipts are pre-conditioned to only show eligible payment gateways for each purpose. Once set they cannot be changed -- we're far too careful with fund routing and the need for consistent reconciliation to let this float after registration opens.

And because we had no better place to put it, the refund deadline (which is purely optional and purely informational) can be set here. This info is displayed in the footer during the registration process. The refund deadline is not enforced in code anywhere - a fact that you'll find particularly helpful when managing registrations in the admin.

Event Calendar

If you are consuming event metadata in your CMS to render a calendar of upcoming events, these metadata fields will be of particular interest. They make it possible for you to set the dates for the event to be included in the feed, a short blurb describing the event, and the ability to roll up a series of events into one group if needed.

We're not going into detail here because most schools don't use this feature; please don't hesitate to file a ticket to have a 1:1 with an AlumnIQ developer so we can best advise you on the most efficient way to get what you need from the data we manage (and understand exclusions and why!).

Miscellaneous

External Event Id is the identifier for this event in another piece of software. In many cases this is the Advance Event ID to simplify integration.
The Short Name field is something that will be unique to this event (you can't reuse the same one for future events). For example, if you organize an event to attend a Phillies baseball game every year, you might use phillies15 this year and phillies16 next year.
Event Gift Appeal Code any gifts made during registration for this event will have this appeal code attached to them; very helpful for identifying the genesis of a particular gift in the long term.

Next?

Upon successful creation of the event you'll be whisked away to the activity configuration screen. An event cannot exist without one activity under it. Head on over to activity configuration for continued detail on the fields present on that form.

If you've just read through this while editing an already-existing event, you'll instead be dropped off at the View Event screen.

View Event

For events that have been created you will be taken to the View Event screen. At the top are three areas that show an overview of the Configuration, Registration, and Marketing details.

Also note the presence of a secondary line of breadcrumbs near the top of the screen. This enables you to quickly jump around setup, customer service, and reporting for the same event without losing contextual focus.

Making a Gift During Registration

If you want a registrant to be presented with the option of making a gift on the invoice step of checkout, you have to map at least one designation (fund) to the event. The idea here is that the gift options are thematically consistent with the nature and purpose of the event.

Gift Designation Assignment

The set of available funds is refreshed nightly from your central database. If you're missing a fund, please contact your advancement services team to confirm the desired fund is being sent to AlumnIQ.

Clicking the Create Gift Designation button will opens a modal window. Both fields are required.
The Designation field is for the name of the Designation, as you type the name of a designation, a list of options will appear below the search field.
Select the Designation you want from that list. Keep typing to narrow the list.
Display Order dictates the order in which Gift Designations will be displayed on the registration form.

Once a fund has been attached to an event, it can only be deactivated (but not removed). Having at least one active fund also will allow you to choose to activate a "browse funds" option if you feel the registrant should be presented with the option of finding a fund not chosen by you for easy selection.

All gift dollars are routed through the gift payment gateway, are tagged with the event gift appeal code (if provided), and are ready for immediate booking and acknowledgement. Whether the event confirmation email is sufficient for a receipt depends on the copy in the email; instiutional standards will define what exactly is necessary for inclusion in order to qualify.

Other fields you may be interested in modifying:

the Event Gift Appeal Code is down at the bottom of the edit event screen. This is the appeal code attached to a gift should one be received via this event registration configuration.
the Gift Blurb is under the "Blurbs" section of the event edit screen - this is the copy that will appear on the checkout screen in context with the fund dropdown and amount fields.

Also of note is that the presence of FMV-applicable fees (see the section on these) will impact the gross charitable portion of the overall dollars collected. Keep that in mind as you frame your wording around gifts.

Event Fees

See the page on event, activity, and product fees for details on fee configuration - you don't want to be too simplistic with these as there are always exceptions to consider. Helpful hint: it's rare that fees are attached to the event; most are set on the activity.

Survey Questions

For some events you will want to collect more information than what is on the registration form. To that end, you can create some survey questions that will be asked on the invoice screen.

Survey questions are for things like:

who is your current employer?
do you have any questions for our panelists?
are you currently looking for a job?

Generally speaking, survey questions are for non-quantifiable information related to the registrant. For quantifiable choices (like what dinner entree would you like, will you need a parking slip, and is the university in your will), use Activity Options. Activity Options are strictly associated with participation in an activity and add context absent from survey questions which are more general in nature.

Survey Question Creation

- **Request From** Allows you to target specific types of registrants with your question. - **Answer Style** Lets you specify what kind of question you want to ask. This cannot be changed once responses have been received. - An **Answer Style** with multiple selections will show the **Options** fields. Each field is used for a different choice. Empty options will not be displayed in the registration form, so don't worry.

Free text responses will automatically include a "not applicable" checkbox to allow the registrant to elect to not provide a response if that is more appropriate for their situation.