Access Controls
updated 2023-08-15 to add "copy paste XIDs" option for all local XID-based ACLs
updated 2023-07-20 to add org ACLs
updated 2022-07-29 to add package ACLs
updated 2022-07-25 to add email-based ACLs
Want to strictly limit the ability to even try to register to a limited audience?
Have a package that should only be visible to a limited audience?
Have an event that should only be visible to a predefined set of people?
Have a special rate you only want a special group of people to receive?
You can do that using our access control list capability.
Which kind do I want (or need)?
An Org ACL is like getting carded on your way in to the liquor store.
A Package ACL is like getting carded at the end of the aisle - Bob decides whether or not you can browse the rum aisle.
An Event ACL is like getting carded as you reach for the bottle of Malibu - Bob is very particular about which bottle you can see (and select).
And an Event Fee ACL is when your ID is recognized at the register and you get a surprise discount for that bottle.
The earlier in the registration process you screen your registrants, the greater the odds of being overly exclusive and creating problems you didn't need. The most common ACL is the Event ACL - it's not too early, not too late - and accomplishes what most are seeking.
Configuration
For orgs:
Setup > view org
Org ACL controls are in the bottom right quadrant of the page.
For packages:
Setup > pick an org > pick a registration group > click on a package
Package ACL controls are in the middle section of the page.
For events and event fees:
Setup > pick an org > Events > click on an event.
Event ACL controls are in the bottom right panel. Event Fee ACLs are in the middle left one.
Special note about Org ACLs
This is the most stringent of filters, and because of that should only be rarely used.
Org ACLs are for very strictly limited events (like a donors-only event) where:
the registrants are all in your warehouse
they can bring zero or more guests (not required to be in the warehouse)
you do not want them to go too far into the registration process before being screened
Org ACLs are different in behavior from the others as well:
applicable to primary registrant only. guests are guests.
scope is locked to individual (just in case that previous rule ever gets changed)
if primary reg fails to pass screening, progress is halted
when an Org ACL is active, the unmatched registration option is not available
Org ACLs are entirely XID driven - no email-based ACL is available (because we haven't captured one to screen against)
Special note about Package ACLs
Think of package ACLs as a super-strict enforcement option to be used when you really, really don't want a package visible to the vast majority of the people who will be transiting the registration process.
Good use cases for ACLs:
Lehigh's Parent's Council meets during Family Weekend and has unique/private programming that should be invisible to everyone else
Dayton's housing situation for reunion is tight, so they only want to offer beds to those who are prior fiscal year donors. This is a package setting, so by ACL-ing the package they can!
Penn's inaugural festivities include a Board of Trustees dinner but they also want a BoT package to simplify reporting. An ACL on a BoT-only package will do nicely.
Your colleagues on staff need to be able to register for everything for free.
Package ACLs are applied downstream of the applicability settings (primary registrant, adult guest, minors, etc.). This means that we effectively pre-qualify registrants before we run the more intensive ACL determination process for each package, improving system performance. Note that for the ACL enforcement to work (for XID-based ACLs), the ACL members must all be in the data warehouse as well. For some events that may not be possible, so please consider that when thinking through possibilities.
Situations in which a package ACL is not necessary or counterproductive:
this package is for a class but also guests of the class
the package isn't anything special and hiding it is for matters of taste and not function
the package is being offered to an audience who can't be identified in an ACL (nor warehouse) with any fidelity
Confused? It's ok! File a ticket and we'll schedule a time to talk through it.
ACL Applicability
The very first setting you're prompted to pick is to scope the applicability of the ACL.
Individual - only that person (as identified by XID or email) will see the package/event/fee. This is rarely used. Party - anyone in that registration party will will see that package/event/fee if any one person in the party is on the invitee list.
Most schools use the Party applicability; it's rare that the family isn't also welcome to attend under the same terms.
Which ACL Type do I need to use?
If your invitee list changes frequently (which is most of them), use an uploaded list.
If your invitee list is reasonably static, you can try for the warehouse.
Why is that? Most customer data warehouses are refreshed at most three times during the registration period. If that warehouse doesn't contain your invitees, they'll never know what they don't see.
And as these invite-only package/event/fee usually involve partners (inside or outside of) advancement, the list is ever-changing - and it's far more efficient for you to upload an artisanally-crafted invitee list as needed without looping in AlumnIQ support.
A little more about types
Warehouse (XID)
refreshed only when we pick up a new warehouse feed, which is 2-3x per major event
setup prompts you to pick a warehouse field and value to lock to
the system matches to the registrant on that config plus an xid
therefore the registrant must self-match for this to work
all invitees must exist in your data warehouse
Uploaded List (XID)
refresh on demand
a more flexible version of the warehouse type (and by far the most commonly used)
the system matches to the registrant on xid
therefore the registrant must self-match for this to work
all invitees must exist in your data warehouse
New August 2023 you can either upload an ACL or paste them into the admin UI
Uploaded List (Email)
a more flexible version of the uploaded list type
entirely email address based (so make sure your registrants are using the one you loaded in)
self-match not required
How to set a Package ACL
Pull up the package in edit mode, scroll to the middle of the screen.
Click on Change Configuration. Pick the ACL type after very careful consideration. Either upload a file (list types) or set the warehouse filter properties as desired. There's a very specific format the file must be provided in; please pay close attention when preparing it.
You can download the last uploaded ACL contents for both upload types from the same panel. Every uploaded list replaces what was there before.
How to set an Event ACL
Pull up the event, scroll to the bottom right.
Click on Change Configuration. Pick the ACL type after very careful consideration. Either upload a file (list types) or set the warehouse filter properties as desired. There's a very specific format the file must be provided in; please pay close attention when preparing it.
You can download the last uploaded ACL contents for both upload types from the same panel. Every uploaded list replaces what was there before.
How to set an Event Fee ACL
Pull up the event, find the panel titled Price Options. Under each option there's a "Change ACL" link.
Click on Change ACL. Pick the ACL type after very careful consideration. Either upload a file (list types) or set the warehouse filter properties as desired. There's a very specific format the file must be provided in; please pay close attention when preparing it.
Not sure which to use?
Drop us a ticket! We'll be happy to advise you.
What does the registrant see?
If they're "on the list", they'll see the package/event/fee as you'd expect. In the event of an Org ACL, they'll be waved in.
If they're not "on the list", they won't see the package/event/fee at all - we don't tease, we simply do not show. In the event of an Org ACL, they'll see a message that they were not on the invitee list.
Last updated
