Events

Currently, AlmaBase offers four ticket types when creating events: Open Ticket, Mandatory Ticket, Sponsored/Team Ticket, Seated Ticket. One challenge our team faces is that ticket purchase deadlines can be set for all ticket types except Mandatory Tickets. This creates a significant limitation for events that require attendees to purchase a ticket as part of a registration while also enforcing a firm registration and payment deadline. While Seated Tickets do allow us to set a purchase deadline, they are not a suitable workaround because Seated Tickets are not truly mandatory. Registrants can still proceed through registration without purchasing a ticket, which defeats the purpose of requiring payment as part of event registration. Please add the ability to configure a ticket purchase deadline for Mandatory Tickets, similar to the functionality currently available for other ticket types.

Description: Currently, the "Let others know I will be attending" checkbox operates at the top-level registrant level. When a registrant checks this box, every individual added to that order is automatically published on the public "See Who's Coming" guest list. The Issue: Many alumni want to be listed on the public attendee roster to encourage classmates to attend, but they do not want their children or family members' names displayed online. Under the current structure, registrants must choose between an "all-or-nothing" setting: either publish the entire family (including minors) or keep the main alumnus entirely anonymous. Proposed Solution: Move the privacy checkbox from the primary registrant level down to the individual attendee level (guest details). Allow a checkbox for each registered attendee (e.g., "Include [Attendee Name] on the public guest list" or "List as Anonymous"). Default main registrants to opting in while defaulting additional guest/child tickets to opted out (or giving the registrant explicit toggle control per person). Impact: This granular control protects attendee privacy—particularly for minors—while boosting overall participation in the "See Who's Coming" feature, as alumni won't have to hide their own attendance just to protect their family's privacy.

When the "What text should appear instead of “Free” for free tickets?" is left blank, I would like it to actually be blank on the ticket selection side. Right now if you leave it blank, it shows up as "Free".

Show the sub-event venue locations on the ticket selection page for guests. Currently, only the description of the sub-event and the time show up, but if I am not using the schedule feature (I don't want all attendees to know about the events they were invited to) I need to show them the location there as well and not just in their guest kit.

Currently, when a registrant modifies their registration (guests, tickets, etc.), Almabase overwrites the original entry with the updated information. While an email notification alerts admins that a change took place, it provides no details on what was altered. Because we prepare nametags and ticket packets on a rolling basis during long registration periods, staff must manually compare old spreadsheet exports against current data to identify changes. We request a built-in change log on the admin record and detailed line-item changes in the notification emails to eliminate this manual workflow.

It would be nice to be able to see what the guest kit looks like, our announcements and such without having to do a test registration to view it.

Currently, the "Event Name" field serves as both the system's unique identifier and the public title displayed to registrants. This creates friction for recurring annual programs (e.g., "NYC Happy Hour"), where we want the public-facing title to remain identical year after year. To keep events distinct in the backend, we are forced to append years or alter titles in ways that aren't ideal for registrant-facing marketing. We would love to see Almabase decouple these fields by adding a dedicated "Internal Event Name" (or backend ID) separate from the "Public Display Name." This would allow admins to maintain distinct records in the database while keeping front-end event titles clean, consistent, and user-friendly year after year.

Currently, Registration Confirmation and Guest Reminder emails within the Events module do not support a “Send Test Email” functionality. Admins today must complete a live test registration in order to review these communications and validate formatting, links, and overall user experience before publishing an event. It would be extremely helpful to have a dedicated “Send Test” option available directly within the Guest Communication workflow for:

Problem: Event Automation invite emails only support one email address, used as both Sender and Reply-To. There's no way to set these separately — unlike Email Communications and manual event emails, which already support independent Sender/Reply-To fields. Impact: Institutions that send from a no-inbox address (e.g. alumnioffice@connect.trinhall.cam.ac.uk ) can't get replies routed to a real inbox (e.g. alumnioffice@trinhall.cam.ac.uk ) for automated invites. Replies get lost. Requested behavior: Add a Reply-To field to Event Automation email configuration, matching what already exists for manual event emails. Scoping notes: Workflow emails already use the same BulkEmail model that has a reply_to_emails field, and the send pipeline already respects it when set — the gap is only that the Workflow layer never populates it and has no UI field for it.