WWU Onboarding
AlumnIQ Platform Onboarding Guide for Western Washington University
last updated February 2021
Purpose
This document is intended to help customers identify, extract, transform, and share data with the AlumnIQ team for a successful onboarding. As much as possible we've limited the content in here to cover the areas that customers can have an impact on; tasks undertaken solely by the AlumnIQ team are not listed here.
Even with that limit imposed there is plenty of food for thought in here. Regarding the warehouse specifically, we'll be actively guiding you through the decision making process - there is a lot to consider and even more to build.
WWU Timeline
Feburary
UP: nothing
IN PROGRESS: domain decisions, Phase 1 warehouse development and delivery, AlumnIQ provisions QA site for preliminary loading and shares IAM credentials to import the phase 1 feeds, all requirements under Warehouse (phase 1) and the Events Module
March
UP: QA site for event setup/training, giving setup/training - conditional on the warehouse phase 1 loading
IN PROGRESS: Discussion about membership structure and sales process, mapping it into AlumnIQ, membership warehouse feeds (see google sheet)
April
UP: Events/Giving 90% to production-grade, membership sales preview (with or without the warehouse feeds)
IN PROGRESS: Email list filters/segmentation to inform Warehouse Phase 2 design completion, directory contents and build
May
UP: Event registration opens for events happening in July, Giving Module live (even if no traffic), Membership module should be good to go, directory in test
IN PROGRESS: warehouse phase 2 and associated list filter builds for use by the email module, list building training
June
UP: Everything.
IN PROGRESS: polish, (re)orientation training, all the little bumps that happen in the cleanup phase
July
Start inviting folks in to the new profile/directory services, iModules goes dark.
General Configuration Guide
We will guide you through all of this - don't be overwhelmed. A good bit of it is described beyond what we'd communicate in person for ease of reference.
Domain(s)
The operating domain name for this deployment takes the form CUST.alumniq.com. If you have a preference for what CUST should be, please share that with us.
What we need: what CUST will be.
Warehouse, Lists, and Filters
The AlumnIQ data warehouse is a set of relational tables that contain all data pushed to us from your system, preferably nightly. This warehouse can be quite large and very detailed. This is why the bulk of the release timeline is dedicated to getting it right.
To de-risk this process, we've split the warehouse generation and delivery into two phases, the first of which you should be able to create relatively quickly:
Phase 1: a core warehouse of commonly used fields with minimal decisions required, a feed of funds (for the giving module), and a shared lookup warehouse feed to map codes and labels for any related information.
Phase 2: extensions that we'll apply as we onboard additional modules. You'll find the feed spec file contains three tabs for membership data - feel free to start work on them anytime. We'll add more tabs for tables of data used for email segmentation - degrees, interests, volunteer activities, student activities, and similar - all of that 1:many data you rely on every day. What form those take will be the subject of more involved conversations about what you use so we can minimize the substance and scope of what you send us to only the necessary.
Once field content is determined and sourced, you'll build the feeds then write a simple exporter to push the data to AlumnIQ. Once we have the data, we'll tweak the importer and build the list filters for the fields identified as filterable in the mail module. Some adjustments will likely be made to the feed structure once you see it live - that's perfectly normal and we're ready to adjust.
We'll do all of that for Phase 1. To prepare you for Phase 2 deliberations, these are some guardrails we've successfully used to guide conversations elsewhere:
Where is this used? Warehouse data is a vital driver for list generation, profile matching, registrant matching, variable email content, and targeted dynamic gift form prepopulation.
We can't use data that you don't provide to us. Also: provide atoms, not molecules. First, Middle, Last, Maiden, Prefix, Suffix as distinct fields is better than "Name" because we can use these atoms for things like pre-filling a first name in the event module, but parsing them out of a Name molecule ("John Jacob Jingleheimer Schmidt '67 P'98") would be nearly impossible.
Similarly, don't apply too many filters right out of the gate. As long as proper record type data exists, we would rather have too many constituents than not enough.
There is such a thing as too much. If it doesn't have a known use in the platform (list segmentation, pre-filling bio data, ask1/2/3, prospect manager) then we probably don't need it.
To paraphrase: Be generous with rows (who), conservative with columns (what)
Normalized data is better. One of the files you will need to send to us is code-to-label lookups, so don't be shy about sending us encoded values unless we've specifically requested a label string.
Related fields Particularly applicable to some list filters. Degree school + type + class year are usually treated as an implicit "AND" when used as a filter term. Please take note those whenever you spot them.
Typical files for sync (by no means an inclusive list)
Warehouse (AlumnIQ-defined spec core feed for platform operations)
WarehouseB (institution-specific 1:1 attributes used for segmentation, reporting, etc.)
Affiliation(s)
Record Type(s)
Degree(s)
Designations
Various lookups/crosswalks
What we need: a description of each feed file with annotations as to what each field means. We've shared a google sheet with you that will be our living source of truth not just for onboarding, but for subsequent modifications throughout your time with us.
xid is the internal id number (alphanumeric ok) that you typically use to refer to a constituent. We also support xid2 if you have a secondary id number you'd like to send along for the ride. Let's work together to make certain that the correct id number is imported as xid because changing them later is painful. You will see XID mentioned all over the place!
What we need: In your case this will be Advance ID. Is it always 10 digits? Do you have a custom format? Will this ID carry over into Ellucian CRM?
Record type seems to frequently be far more granular than you would want to display to constituents. You should be prepared to map your record types to a set of 8-10 "displayable" record types for self-selection in event registration, profile creation, etc.
Ex: Alum, Student, Parent, Spouse, Family, Staff, Faculty, Community/Friend/Other
Mappings would indicate "Undergraduate alum || graduate alum || former student => Alumnus"
What we need: a mapping table that maps your record types into a more generic set. the core warehouse expects a primary record type for shorthand identification.
Global opt-out/removal flags
Which warehouse field(s) need to be obeyed across the board (if any)?
What we need: which fields need to be automatically applied and made 100% unescapable
What we need: a column representing your global do not contact flag. this will be subject to much internal deliberation, which is why the control for who gets flagged is entirely driven in code on your end of the pipeline.
Directory controls
The constituent directory exposes a significant amount of constituent information to other human beings. With this exposure comes the consideration for healthy limits. So that you retain tight control in alignment with your own internal business rules, we require that you provide the following columns in your base warehouse table, set accordingly:
directory_access - grants permission to access and search the directory
directory_visible - whether this individual should be searchable and visible
directory_contactable - for a listed individual, whether they should be allowed to be contacted by other constituents through the directory messaging tool
directory_can_email - for an individual who can access and search the directory, whether they are allowed to send messages (this is our passive aggressive persona non grata setting)
all of these should be in 0/1 or Y/N format, whatever your convention is across the board
Sending this data to us
You'll move each file to a private Amazon S3 bucket accessible only using an access key and access secret we'll provision for you. This is easily scripted.
After the file is moved, you'll call a webhook (really just a glorified URL) telling AlumnIQ to pick up a file named X and load it as warehouse feed Y.
You'll get an email or webhook callback (your choice) when each job completes. If there's a problem, you'll be notified as well.
Every warehouse table is replaced in its entirety every night. We run off of your snapshot for ease of diagnosis and stable content.
Events Module
Items to provide
Categories
one per event
typically used to make each department/org's events easily findable, but that's certainly not a rule
Examples: Alumni Association, Annual Fund, Colleges
What we need: category names
Subcategories
one or more per event
used to further refine the definition of the nature of the event
Examples: Affinity, Athletics, New York Alumni Club, Trustees, Alumni Board
What we need: a set of labels
Email Sender
Default Sender and Reply-To names and email addresses for confirmation emails. The address must be from an authorized domain (see Email for more information).
What we need: a label and an email address. Sender: "WWU" no-reply@wwu.edu Reply-To: "WWU Alumni Association" alumni@wwu.edu as one example. The sender must be from the "sending domain" as identified later on (@alumniq.wwu.edu, @adv.wwu.edu, or one we manage @wwu.alumniq.email). Reply-to can be (and we recommend) any @wwu.edu address that is monitored.
Default Configuration
Default for address collection for free events. When true, we will ask for the mailing address of the primary registrant even if no money is collected. For some, if the registration is free this information does not provide enough value to slow down the registration process for the registrant.
What we need: your default election
Visibility defaults for the following fields (required, visible, or hidden):
Prefix
Nickname
Suffix
Phone
Mobility Needs
What we need: your defaults for each
Event Location seeds (Optional)
AlumnIQ builds a database of event/activity locations over time for each customer. You're welcome to start fresh, but if there are key locations that you've used many times we can bulk load them up front and save some work.
What we need: Name, URL, Phone, Address 1/2, City, State, Postal Code, Nation, Latitude, Longitude
Accounts
AlumnIQ records event revenues in a double entry accounting system
All events must be attached to an income account
Activities within that event can be attached to separate income accounts
You can add more accounts over time as needed and deactivate old ones.
To get started we need your initial set of accounts.
What we need: a spreadsheet of account label, account code (your internal account reference), and subaccount code (a secondary internal account reference, optional)
Zoom API Keys (optional/recommended)
We can integrate with Zoom for meetings and webinars; to do so we need JWT API Keys (not OAuth!). If you want to activate this capability, start conversations with your campus Zoom admin early. They take a close eye to third parties who want to use their keys.
What we need: see https://help.alumniq.com/events/webinars#managed-zoom-activation
Default Site Skin
We will clone your site layout. We will need you to provide the officially sanctioned/permitted logo artwork
What we need: graphics (if we can't source it ourselves)
Payment Gateway Credentials
We will connect to your payment gateways to process payments and gifts using the Spreedly service.
Spreedly will need credentials to connect to your gateway(s); those requirements vary per gateway
Once we identify what you're using we'll tell you exactly what we need.
What we need: gateway types and roles, and credentials once we know what you use
Online Giving Module
Vocabulary
Giving tends to have a lot of words in common with other areas of the business or loaded terms, so we had to choose the names of these things carefully to avoid confusion. As used in this document, each of the following words has the meaning outlined below.
Path - A customized giving "landing page" with its own skin, email template, set of featured designations (and flag for enabling "other" search), and default gift amount.
Pitch - A customized request for a gift. The pitch points the donor to a specific path, may optionally override the default gift amount, and default recurring/installment iterations. You can think of a pitch as a campaign for a specific path (path: football team, pitch: new bleachers project)
Personalized pitch - Pitches allow you to customize what appears on the path form for the current situation, but pitches can also be further customized if you have the data available. You can send donors personalized links that have the amount pre-filled to a value specified in the warehouse.
Pledge - A set of one or more gifts made in the same session, and the schedule for collection (one time, installment, or recurring).
Gift - A designation and amount.
Explanation of settings
Our giving module is designed to be very dynamic based on how granular you wanted to collect certain pieces of information. A number of settings you'll see mentioned below are said to be per gift, per pledge or not at all. The system allows you to specify some items as configured on each gift to a designation (per gift), or for all the gifts that were submitted (per pledge), or if you don't care about collecting this information we can hide it. Each setting can be set as a default at a higher level so you don't have to worry about it at all or we can set it as a default per path and allow you to adjust it as you see fit.
Items to provide
Employer Match: We're partnering with Double the Donation to enable dynamic company match support; this requires a separate contract with them if you wish to enable it. Otherwise, AlumnIQ supports a simple text input field for employer name that your gift processing team can follow up on.
Special Instructions: We can provide a box to allow the donor to enter any additional instructions or notes that go along with the gift. We need to know if you want this collected per gift, per pledge, or not at all and the placeholder text to put in the text box (this placeholder text is never recorded in the final record and is erased as soon as new text is entered into the field).
Minimum charge. If you have a minimum that you will allow each credit card transaction to be, whether it be a one-time, recurring or gift made in installments, we can configure that. This minimum is per-transaction. We do a lot of validation both on the donor page and on the server to be sure that each transaction would be over the minimum and will encourage the donor to increase or reconfigure their gifts until the minimum is met.
Allowable days to collect recurring gifts and an installment on a gift. You can allow the donor to select recurring/installment payments be collected on certain days of the month, e.g. 1st, 15th, or 28th. If you provide multiple options, the donor must choose one from a dropdown on the giving form. When providing more than one option, you may specify which one should be selected by default. Alternatively you can provide only one day of the month, and the donor will be informed but not given a choice. We need to know at least one day of the month for payments to be collected and it should be between the 1st and 28th, inclusively. We skip 29-31 to avoid the extra date math for months that don't have them. Regardless of this configuration, the first gift payment is collected on the date the gift is created - so we will capture those tremendously important December 31 and June 30 gifts regardless.
Tribute fields. We can allow the donor to check a box that signifies that this gift should be in honor of, in memory of, and/or on behalf of someone. Selecting the checkbox will expand fields that presents a text box for each type of tribute. This can be configured for collection per gift, per pledge or hidden. You also have the ability to activate additional fields for who to notify in the event of an IHO/IMO gift.
Maximum Number of Failed Payment Attempts. For recurring and installment gifts there will be cases where cards will become unusable such as expired or account closed. This setting specifies how many times we try before we stop trying again. Reminders will be sent to the donor asking them to update their card information after each attempt.
Default path setup. We can help you configure your default path to help you get started. You will need to know the designations that should be presented as focused selections - we'll construct a starter template to surround it. Please remember that the giving form was built with a mobile-first mindset so your wrapper for this and any additional paths must also be responsive.
The following are supplied as a comma-delimited list of email addresses and can be added or maintained in admin under "Settings" section of the giving module. 1. Daily Summary Email Recipients. Every morning the system will generate and send a summary of all new pledges from the last 24 hours. 1. Pledge Alert Email Recipients. As each new pledge is created, these email addresses will receive an immediate summary. 1. Event Designation Change Recipients. If an event manager adds, activates or disables a new gift designation on an event.
Email Marketing Module
Email sending domain (CUST.alumniq.email or @SUBDOMAIN.wwu.edu if your DNS admins are so generous)
If you want to send from @CUST.edu addresses, DNS entries will need to be made (attached to your sending domain) to maximize deliverability. We can't do this for you - it's a central IT function.
Reply-To addresses are exempt from this requirement, though we cannot ensure that some mail servers won't look sideways at the domain mismatch.
Mailgun requires all sending domains to be validated. This means we cannot send from @CUST.edu addresses without these DNS modifications
What we need: what your sending domain(s) will be and contact info for the DNS administrator (if necessary)
Subscription categories
These categories are visible to constituents on their profiles.
When message recipients unsubscribe, it's from these individual categories. This limits the 'blast radius' of an unhappy recipient to just a certain class of messages.
"Not too many, not too few". You'll want enough granularity that people aren't clicking unsubscribe 12 times, but also not so general that unsubscribing from one category removes the individual from 80% of your email messages.
Categories can be generic (Events, Solicitation, Newsletters) and more targeted (NYC chapter, LGBTQ+ affinity organization) depending on how many choices you want to present to your alumni.
Categories can be easily added. Reorganizing and removing categories is perlious and requires careful coordination to realign/reassign existing preferences to the new structure.
What to provide: label for each subscription category, a human-friendly description, and an optional code. We will have a lengthy conversation about how these are structured and the implications for how you break them down.
Categories - entirely separate from subscription categories.
one per message
typically used to make each department/org's messages easily findable, but that's certainly not a rule
What we need: category name and the color you'd like each to appear in on the message calendar (hex preferred)
Subcategories
zero or more per message
Used to capture the nature of the message at a high level. Examples include: Affinity, Engineering, Events.
What we need: label for each
Tags
zero or more per message
Editor-created/selected terms that help with future quantification and roll up of message performance.
Examples include: service, baseball, affinity, fundraising, happy hour
Messages and Images share a tag library so whatever tags you preload or create in the course of using the system, you'll have available in both areas. We did this deliberately since the features are so intimately bound.
You don't need to seed the list of tags but you're welcome to. These may have perfect overlap with Subcategories but also allow for user-created tags to be applied. This is another layer of metadata useful for reporting purposes.
What we need: optional list of labels
Default sender info
As an editor, you can change the sender name and email address. We default both fields to a common/acceptable value.
What we need: a label (like "EDU Alumni Association") and email address (like "alumni@school.edu"). Only one label/address pair can be set as the default.
Personalization/Tokens
The subject line and all editable body regions support token replacement - strings that are replaced with personal information that represents the recipient.
Not every field in your data warehouse should be made available for tokenization
Typical fields include: xid, first name, salutation, spouse/partner name, ask 1/2/3, prior fiscal year giving, address information, and so on.
What we need a list, based on your specific warehouse implementation
Default list filters: E.g. excluding constituents who have been marked "do not contact ever" and "do not solicit." The idea is to save the list builder the effort of remembering to add these filters in every time and prevent sending to people you shouldn't.
We can do a mix of global defaults and per-person defaults so that people who work on different teams with different goals can have different default filters.
Default filters can be marked "protected" on a per-filter basis, which prevents them from being removed by the staff member unless they have been granted permission to do so.
What we need: your most common filters, and with that whatever questions you've formulated from looking at your current segmentation strategy so we can recommend optimal defaults.
What we need: a single column in your warehouse that represents the "global do not contact" flag. People with this flag "up" will not be contactable through the AlumnIQ platform at all - consider this your institutionally-driven failsafe. We will respect this warehouse value above all others.
Mail Templates
Places we send email:
mail module - several layout templates can be built right in the AlumnIQ admin using the drag and drop template builder
event confirmation - one layout template is required (default), multiple supported
transactional messages (one common template)
[events] request for payment / confirmation / receipt
[profile] email address control confirmation
[profile] password reset
[profile] match available (customer dependent)
[admin] password reset
[mail] threshold notifications (unsubs/opens/clicks)
giving messages
confirmation/receipt
scheduled payment notification
card expired/expiring
payment failure
membership messages (pending refinement)
confirmation
card expired/expiring
payment failure
What to provide: a logo/header image to park at the top of the template for notifications (max 600px wide, however tall); we'll build a starter templates that you can then maintain as needed. Any templates we create will be responsive and mobile-friendly.
Directory & Profiles Module
Key Questions
Who will be permitted to create a profile?
Typically this is "literally anyone"
Whether they match to a warehouse record is discussed later on.
It is that match to a warehouse record and the attached affiliations that will determine access permissions to different areas of functionality.
How will we be logging people in?
AlumnIQ supports Shibboleth, OAuth, and OIDC for authentication.
We can support using your campus auth service for current students, faculty, and staff - and alumni too if you offer lifetime accounts.
If you do not have that service available or do not wish to integrate it, a standalone AlumnIQ auth service can be spun up (Shib, OAuth, or OIDC to mirror the campus provider)
If we are using a campus auth service, be sure to include a column in your base warehouse table that represents the value returned from your authentication service. This is typically an ID (Advance ID, RE Constituent ID, Banner ID, etc.) - we can't pair a login to a warehouse record without it.
What will be available for display and edit on your constituent profiles?
First, nickname, last, salutation, address, employment, phone number(s) - the list is extensive.
We don't restrict your field set; it'll depend on what you find useful/meaningful and want to use for updates to your core database and/or display/filtering in the directory.
Who will be allowed to update their address?
Alumni typically can update their contact information without interference.
Students typically cannot and should be directed to the registrar to do so.
Are certain fields of the profile visible and modifiable by only certain types of constituents?
Alumni almost always have employment info fields. Students (graduate, adult learner/continuing ed, etc.) will too. Undergrads may have these visible to share summer/off-semester employment experiences.
Spouse/partner info, degrees from other institutions, etc.
Decisions here will depend on what you choose to make available on your profiles and the extent to which it can be atomized for update in your database.
Data Needs
Email address for directory support: Who should be contacted by a constituent that needs help? (e.g. directory-support@school.edu)
What we need: what that email address should be.
We have the ability to auto-match a newly created profile to its warehouse record if-and-only-if certain aspects of the signup form perfectly match the same aspects of a warehouse record. We'll work together to determine what those aspects should be. 1. Anyone not auto-matched to their xid will stay in a "provisional" status until they are matched. 1. There are admin tools for staff to manually search & match. 1. Matching may also be done via API. 1. Provisional profiles only permit the constituent to update their profile and access any public areas of the system. Spaces like the directory are restricted to certain matched constituents only.
What we need: to have that conversation about what qualifies as a certain match
As mentioned in the directory/profile section above, identify the ID field in the warehouse that corresponds to the response from your campus authentication provider for autoprovisioning functionality to work.
Affinity Groups 1. We support two types of affinity groups: Self-selected (e.g. Black Alumni Network) and School-assigned (e.g. Honors Society). 1. There are admin controls for setting up and maintaining self-selection affinity groups. Management of school-assigned affinity groups will be done via warehouse sync. 1. Self-selected additions and removals are timestamped and logged for sync purposes (should you decide to keep your database updated with these memberships)
What we need : for each group - Name (relatively short), description, and optionally an internal id or code. If you don't provide an id we'll use the name as id, so it must be unique.
Shadow ban status can be managed via warehouse sync or via AlumnIQ admin.
Matching a record provides verified Affiliations, which we use for access to the directory, among other things. (e.g. only Students and Alumni can search it). Additional affiliation overrides can be added (additive only) as a stop-gap for immediate resolution of an incorrect record or when it is known that the record will not be matched but the user should have the access of a particular affiliation.
Subscription preferences are 100% self-service capable, but sometimes a VIP or squeaky wheel wants someone to change it for them. Staff may modify the subscription preferences of any profile.
Constituents may unsubscribe from email subscription categories prior to creating a profile. After profile creation and matching, their existing preferences will be visible and editable in their profile.
Genders: You may choose whether or not to collect gender on profile. If yes, we'll need a list of gender options. We do support a self-described option where the constituent enters their own (e.g. "prefer to self-describe").
Name prefixes: We'll need a list of prefix options to select (e.g. Mr, Mrs, Dr), but please take care to make sure these cover all possible selections for gender.
Directory search criteria work similarly to List Filter criteria in the email marketing module, but are generally fewer and simpler to keep things easy for constituent users. We'll work together to identify the right fields on which to allow searching.
Email Forwarding Module
Email forwarding services are available as an extra cost option that not all schools elect to activate. Billing is based on volume.
Key Decisions
Who may create a forwarding alias? (Typically: Alums)
Domain (@alum.school.edu, @schoolalum.com, etc)
Do we need to import any existing aliases?
Data Needs
If importing existing mail forwarding aliases, we'll need:
xid
alias (foo@alum.school.edu)
recipient (foo42@bar.co.uk)
Last updated