The Business
ABC Events powers everything chapters do to bring their communities together — from networking receptions to technical training to board meetings. Understanding the business model helps you catch edge cases that matter.
🎯 What ABC Events Is Actually About
ABC Events is not a ticketing platform for consumers. It's an internal tool for chapters to manage their own events and members' participation. A chapter might host 20–100 events per year — some huge and formal, some small and casual. Members need to know what's happening, and chapters need visibility into who's coming and how much to collect in payment.
The module serves three audiences simultaneously: Chapters manage events, members browse and register through the portal, and National gets uniform data across all chapters for reporting and compliance. This creates some interesting constraints. For example, chapters can manually create and edit registrations in their internal interface, but the portal registration flow is more rigid because it needs to maintain data integrity across many simultaneous users.
An event is fundamentally just an occurrence with a date, a location (optional, can be virtual), and a set of activities called Functions. But it's also a revenue generator. Chapters can collect registration fees, sell sponsorships, and upsell add-ons. The system tracks all of that.
👥 Who Has Permission to Do What
Events access is controlled by staff level and explicit Events Permission. Chapter Staff Level 2 with Events Permission can create, edit, and delete events. Level 1 staff can view events. Portal users can see events without needing special permissions, but the moment they register, they're creating data in the system, and registrations respect the availability windows and capacity limits set by staff.
This matters for testing because it means the same event data can be modified through two different interfaces with different rule sets. Staff can override almost anything (manually add registrations, force payments, adjust pricing). The portal cannot. This is intentional — chapter staff need flexibility — but it means you need to test both paths.
📊 Event Value: What Members Get, What Chapters Get, What National Gets
For members, Events are simple: find events they care about, register, pay, attend, get confirmation and possibly a badge. It's straightforward value — access to community and learning.
For chapters, Events are operational and financial. They can plan and execute events, see who's attending, verify payments, send communications, and report on success. They can control pricing (member vs. non-member rates, sponsor levels), set capacity limits, and handle special cases (comped tickets, invited-only events).
For National, Events create a uniform data stream. They see aggregate event numbers, attendee demographics, revenue, and adoption patterns across all chapters. This helps National understand where events are thriving and where they need to invest.
🏗️ The Event Structure: Event → Functions → Tickets → Registrations
Events are organized in a clean hierarchy. At the top is the Event — a single named occurrence with a start date, end date, location, and a bunch of metadata (description, max registrants, event status). Many events are one-shot (a single networking happy hour), but events can span multiple days.
Under an Event are Functions — the actual activities that make up the event. A multi-day conference might have Functions for "Day 1 Breakfast," "Day 1 Keynote," "Day 2 Workshops," etc. A simple networking event might have just one Function. Functions have their own dates, times, locations (can differ from the event location), and speakers.
Tickets are optional and can be tied to zero, one, or many Functions. A single-ticket event (everyone pays the same to attend) has one ticket. A dinner event might have "Gala Ticket (Table of 8)" and "Gala Sponsor Ticket." Tickets carry pricing (separate rates for members vs. non-members), capacity limits, custom fields to collect from attendees, and "included items" (other tickets bundled into a package).
Registrations are the records created when a person signs up for a ticket. One registration per ticket option selected. If a person buys two different tickets for the same event, they get two registration records. This is critical: each registration is a separate record, but attendees appear once in the attendees list regardless of how many registrations they have.
How It Works
Understanding the complete event system: from creation to registration, payment processing, and attendee management
✏️ Creating the Event: The Bare Minimum
Chapter staff can create an event with just three pieces of information: Event Name, Start Date, and Event Status (defaults to Active). Everything else is optional. This might sound permissive, but it's intentional — staff often need to create a placeholder event quickly and fill in details later.
The optional Event Details tab lets them add event description (a rich WYSIWYG editor), end date (defaults to start date), times (12-hour format, no seconds), a chapter staff contact (dropdown of active users), an external contact (free text for off-system people), classification/sub-classification (for organization), region, max registrants (capacity), and three memo fields (general notes for staff, memo to print on confirmation, memo to print on invoice).
The event is immediately visible in the Chapter Site and (if status is Active) to portal members browsing events. Staff can edit everything at any time, and all changes are tracked in change history.
📍 Setting the Location (Physical, Virtual, or Hybrid)
Locations are managed as standalone records. A chapter can create a physical location (with address, phone, directions, contact info) and reuse it across multiple events. Locations can be marked Active or Inactive (inactive ones don't appear in dropdowns).
When assigning a location to an event, staff can pick an existing physical location, a company location (pulling from AMS company records), or leave it blank for virtual. If virtual, they enter a link/URL instead. The location info appears on event confirmations — address, phone, directions for physical events; the virtual link for virtual events.
The key insight: location is optional. An event doesn't need a location to exist. This is useful for virtual or hybrid events, or for planning placeholders before the venue is locked in.
🔄 Adding Functions: The Event's Activities
Functions are optional components that break an event into distinct activities. A one-day networking event might have just one Function ("Networking"). A two-day conference might have Functions for each day and session. A volunteer day might have Functions for different project sites.
When adding a Function, staff sets the name (required), start/end date/time (defaults to event start/end), location (defaults to event location, can differ), and speaker. All times display in 12-hour format.
Functions can only be deleted if no registrations exist for that Function. This is a hard constraint — registrations reference Functions, so you can't orphan data by deleting a Function.
🎟️ Adding Tickets: The Pricing & Capacity Layer
Tickets are where the business logic lives. A ticket has a type (single ticket, table/team ticket, or sponsor ticket), a name, description, and pricing. Member and non-member rates can be different. There's an optional "Other" category for custom attendee types (e.g., "Student," "Government Employee") with custom pricing and description.
Max Available controls capacity. If blank, the ticket is unlimited. If set to a number (e.g., 100), portal users see "Sold Out" once 100 registrations are reached. This limit is enforced both in the portal and when staff manually add registrations in the Chapter Site.
Tickets can have a tax percentage (for physical items/swag). The tax is calculated as percentage, not flat addition. Example: $20 ticket + 5% tax = $21.00. This matters for invoice calculations.
Tickets can be tied to zero, one, or many Functions (optional). They can also bundle other tickets as "Included Items" (common for sponsor packages). For sponsor tickets and table/team tickets, you specify attendee count rules.
Tickets also have custom fields — ticket-specific attributes collected from attendees during registration. A gala ticket might collect "meal preference." A conference ticket might collect "t-shirt size." These must be added before registrations occur.
⚙️ Registration Availability: Windows & Capacity
Chapter staff control whether portal registration is open. They set Enable Registration (checkbox), Registration Start Date/Time, and Registration End Date/Time. When registration is disabled, portal users cannot sign up (but staff can still create registrations in the admin interface). When registration is enabled but before the start date, the portal shows the event but hides the register button. After the end date, same thing — event visible, but registration closed.
There's also a Requested Invoice Due Date field that sets the default due date for invoices generated when members request an invoice instead of paying immediately.
Tickets & Pricing
Dive into how tickets work, why the pricing model exists, and how capacity is enforced across the system.
💰 The Pricing Model: Member vs. Non-Member vs. Other
ABC Events allows chapters to offer different pricing based on attendee type. Every ticket has a Member Price and Non-Member Price. The portal automatically applies the correct price based on whether the registered person is from a member company or not.
There's also an optional "Other" category — a custom attendee type that chapters can define (e.g., "Student," "Government Employee," "Spouse"). Each Other category has a description, pricing, and is controlled by a checkbox. Chapters can define one or many Other categories per ticket, each with different pricing.
When someone registers through the portal, the system automatically selects the right price based on their company's membership status. Staff registering people in the admin interface explicitly select which category they're registering the person under.
📦 Included Items & Bundling: Sponsor Packages
Sponsor tickets typically include other tickets or benefits. The Included Items feature lets you bundle tickets together. A "Gold Sponsor" ticket might include "VIP Dinner Ticket (2)" and "Reserved Parking Pass." When someone buys the Gold Sponsor ticket, the included items are automatically added to their package.
Included items affect capacity calculations. If a sponsorship ticket includes a VIP Dinner Ticket, and VIP Dinner has a capacity of 10, the system decrements available spots appropriately. If you have 2 VIP Dinner spots left and a sponsor buys a package with 2 VIP Dinners, the next sponsor sees "0 available."
Custom fields from included items are also auto-populated. If your VIP Dinner collects "meal preference" as a custom field, sponsors buying that package will have that custom field auto-populated from the included item.
📊 Tax Calculation: Percentage-Based, Not Flat
The tax field on a ticket is a percentage, not a flat dollar amount. This is important for invoice and payment calculations. The formula is simple: Tax Amount = Price × (Tax % ÷ 100). Example: $200 ticket with 5% tax = $200 × 0.05 = $10 tax, for a total of $210.
Tax is typically used for physical items or swag. A training event might have 0% tax (purely service). A gala with a silent auction basket and meal might have 5–10% tax depending on local regulations.
Tax is calculated per registration record. If a person buys two tickets, each ticket's tax is calculated separately and summed. The invoice shows both the original price and tax per line item.
🛑 Capacity: Max Available Enforced Everywhere
Max Available controls ticket capacity. When blank, the ticket is unlimited. When set to a number, the portal users see "Sold Out" once that many registrations exist. Portal users attempting to checkout see a capacity error if the ticket is sold out.
The critical rule: capacity is enforced both in the portal AND in the chapter admin interface. Staff cannot override capacity when adding registrations. If a ticket has 10 spots and 10 are taken, the staff member attempting to add the 11th registration gets a validation error and cannot proceed.
Capacity is also checked at checkout time in the portal. If you add a ticket to your cart and then other shoppers fill the remaining spots before you checkout, your checkout fails with a specific capacity error. This prevents overselling but means cart items are not reservations — they're just placeholders.
Registration Flow
How people sign up for events — whether through the portal or via chapter staff — and what gets recorded in the system.
👤 Portal Registration: Steps 1–4
Portal users follow a linear registration flow. Step 1 (Contact Information): The system displays Email, First Name, Last Name, and Company fields. If the user is logged in, these auto-populate from their contact record and can be edited (edits apply to the registration only, not the database). If not logged in, the user must log in or create an account — guest checkout is not allowed. After authentication, fields auto-populate, and the user proceeds.
Step 2 (Select Ticket Options): A table shows available tickets with name, description, price (member/non-member as applicable), included attendees, available spots, and a quantity selector. Sponsor tickets with included items auto-decrement the available spots count. Users select quantities and proceed.
Step 3 (Registration Information): A summary of selected options appears at the top. Below that, expandable sections for each ticket option allow users to enter attendee details. Custom fields specific to each ticket appear inline. The first attendee auto-populates with the registrant's info (editable). Remaining attendees default to "Reserved Attendee" if not entered. All fields except Additional Info are required for the first attendee. Each ticket option creates a separate registration record, so a person buying two different tickets creates two registrations. JIRA ONLY · ABC-2713 JIRA ONLY · ABC-2707
Step 4 (Summary & Payment): The system displays a summary of all registrations with total price, quantity, and included items. Users choose a payment option: Pay Now (immediate credit card or ACH), Request Invoice (create unpaid registration and generate invoice), or Add to Cart (hold for multi-event checkout). Portal changes to read-only at this step (confirming the selections before payment).
🏢 Chapter-Side Registration: Full Control
Chapter staff can create registrations directly in the Chapter Site, bypassing the portal's step-by-step flow. The Add Registration form shows the full picture at once: registrant (individual + company with type-ahead and add-new capability), ticket selection, custom fields, and payment info.
Unlike the portal, staff explicitly set the payee type (company vs. individual), the specific payee entity, payment status, and registration source (a dropdown lookup, not free text). They can also record notes and a PO number for corporate payments.
The key differences: staff can create registrations outside the availability window (the registration window doesn't apply to admin-created registrations), but capacity limits still apply — staff cannot exceed Max Available. Staff also cannot directly enter payment details on the registration form; instead, they use the "Mark Paid" button to navigate to the invoice, where they record payment.
📋 Registration Records vs. Attendees: Why the Distinction Matters
This is subtle but critical. A Registration is a record created per ticket option selected. If you buy two different tickets, you get two registrations. If you're the primary attendee in a sponsor ticket with quantity 5, five registrations are created (one per attendee in the package), but they all reference you as the company/registrant.
An Attendee is a person actually attending the event. The attendees list shows each person once, regardless of how many registrations they have. This prevents duplication. If you register for both the Gala Ticket and the After-Party Ticket, you appear once in the attendees list with both tickets shown.
Sponsor auto-creation compounds this. When you create a sponsor record with a quantity of 3 attendees, three registration records are auto-created: one for the sponsor's primary attendee (registrant), and two "Reserved Attendees." All three appear in the attendees list. JIRA ONLY · ABC-2865
👥 Reserved Attendees: Placeholder Names
"Reserved Attendee" is a placeholder. When a table ticket or sponsor ticket is created with multiple attendees and staff doesn't specify a name, "Reserved Attendee" is used. Staff can edit these later through the attendees tab or through the registration. Portal users can also update attendee information in the "My Events" section until the registration window closes. JIRA ONLY · ABC-2704 JIRA ONLY · ABC-3314
💼 Sponsor Auto-Creation: From Ticket to Attendees
When a sponsor record is created or updated, attendees are auto-created based on the sponsor ticket quantity and included items. The primary attendee defaults to the sponsor's registrant info. Additional attendees are set as "Reserved Attendee" and can be named later.
If the sponsor quantity is increased, existing attendee data is preserved and new attendees are added. If decreased, the system warns before removing attendees. Custom fields from included items are auto-populated.
The sponsor attendee flag is set automatically, making it easy to identify sponsor vs. regular attendees in reports and filtering.
Getting Paid
How members pay for events, how invoices are generated, and what happens after payment is recorded.
💳 Payment Options: Three Paths
Portal users have three options at the end of Step 4: Pay Now, Request Invoice, or Add to Cart.
Pay Now takes the user to a payment screen with two methods: credit card (via configured gateway like Authorize.net) or ACH (automated clearing house transfer). Payment processes immediately, and the registration is marked Paid. An invoice is auto-generated as a paid invoice (transaction record).
Request Invoice creates a registration marked "unpaid" and auto-generates an unpaid invoice. The event has a "Requested Invoice Due Date" field that sets the due date for these invoices. Members can view and pay the invoice later through the portal or directly.
Add to Cart holds the tickets without creating registrations. Multiple events can be added to the cart, and checkout processes all items at once. Cart items do NOT create registrations until checkout is complete. If a ticket sells out while items are in the cart, the checkout fails with a capacity error.
📜 Invoice Generation: Automatic & Complete
Invoices are auto-generated in two scenarios: when a member requests an invoice during registration, or when a payment is completed (Pay Now). The invoice is generated with all details pulled from the registration: event name, ticket name, price, quantity, tax, registrant, payee, and total.
Zero-dollar invoices are created for free events. This might seem odd, but it's important for consistent reporting and accounting. A free event still needs an invoice record to track the transaction.
Invoice numbers are auto-generated in a standard format. Invoice status tracks whether payment is pending or complete. All invoices track invoice date, due date, and payment date/method.
🏢 Chapter-Side Payment Recording
Chapter staff don't directly enter payment information on the registration form. Instead, they use the "Mark Paid" button on a registration, which navigates to the associated event invoice. From there, they record payment: credit card (via configured gateway), check (manual entry), cash (manual entry), or other method.
Once payment is recorded, the registration status and invoice status both update to Paid. Payment date and method are recorded.
📧 Communications After Payment
When payment is recorded (any method — online or manual), the system sends a Payment Confirmation email. When a registration is completed via portal (request invoice), a Registration Confirmation email is sent immediately. These are customizable per-event templates (not system-wide). The templates support WYSIWYG editing and can include event details, registration summary, and payment instructions.
Chapters can also manually send an unpaid invoice reminder to selected invoices via the Invoice list.
Coupons & Discounts
How chapters offer discounts through coupon codes and manual discounts, and how portal users apply them.
🎟️ Coupon Codes: Percentage or Dollar Amount
Chapters can create coupon codes for events. Each coupon has an alphanumeric code (unique per chapter, no spaces), discount type (percentage or fixed dollar), discount value, event scope, usage limits, and expiration date.
Event Scope controls where the coupon applies: All Events (every ticket in the chapter), Selected Events (multi-select dropdown), or Selected Event Tickets (pick an event, then specific tickets within it). This gives flexibility — a "Summer Promotion" code might apply to all events, while "Gala VIP Discount" applies only to the gala's sponsor ticket.
Usage Limits: Max Usage Count (blank = unlimited, numeric = maximum total uses across all users), and One-Time-Per-User (if checked, each person can use once, preventing multiple uses by the same individual).
Expiration Date: Optional date picker. The coupon status auto-transitions to Expired when the date passes. Expired coupons cannot be applied in the portal.
✂️ Portal Coupon Application: Restricted to Logged-In Users
During portal checkout, members can apply coupon codes via a text input field with an Apply button. The system validates the code in real-time and displays discount details: original price, discount amount, and final price.
Non-members must log in to apply coupons. This is a security measure — it prevents malicious code sharing and ensures discounts are only available to legitimate members. If a non-member attempts to apply a coupon without logging in, they're prompted to log in first.
One-time-per-user validation returns a proper error message (not a 500 error) when the same user attempts a second use. The message should clearly explain that the coupon has been used and cannot be used again.
Users can remove a coupon before final checkout if they change their mind.
🛠️ Manual Discounts: Staff-Side Override
Chapter staff can manually apply discounts during registration creation in the Chapter Site. They select discount type (percentage or dollar), discount value, and optional notes (e.g., "loyalty discount," "staff courtesy"). The system auto-calculates the discounted price and preserves the original price for reporting. The staff member who applied the discount is tracked (audit trail).
📊 Discount Reporting: Visibility & Tracking
The registrations tab shows discount-related columns: Discount Applied (Coupon Code, Manual Discount, or blank), Discount Amount (dollar), and Discounted Price (final price). This allows staff to review discount history at a glance.
Metabase reporting provides aggregate discount analytics: total usage count, revenue impact, usage by event, member vs. non-member split, and usage timeline.
The Portal
How members experience events — browsing, registering, and managing their registrations online.
🔓 Public Access Without Login
The portal events area is accessible at `/portal/events` without requiring login. Members can browse events, see details, and view pricing. Only current and upcoming events are displayed (past events are hidden). The URL can be shared publicly, making it easy for chapters to promote events to non-members too.
Portal access depends on the portal being enabled; if the portal is disabled for a chapter, the public events area is not accessible.
👁️ Three View Modes: List, Grid, Calendar
The browse events screen offers three ways to view events: List View (tabular), Grid View (cards), and Calendar View (month navigation). Users can switch between views, and the chapter has a default view setting in Manage Portal Settings (defaults to List, Grid, or Calendar). Users can switch after landing on the event list.
All views support search (full-text across event names and descriptions) and filtering by Location and Classification (only classifications for upcoming events are shown).
🔐 Login & Registration: Authentication Gatekeeper
Browsing and viewing event details require no login. But clicking Register on an event requires authentication. If the user is not logged in, they're prompted to log in or create a new account. Guest checkout is not allowed.
After authentication, the portal registration flow begins at Step 1. If the user is already logged in, they skip the login step and go directly to Step 1.
First-time users creating an account go through email verification. Once verified, their contact record is created and they proceed to Step 1.
🎯 Portal Registration Step 1: Contact Information
If logged in, Email, First Name, Last Name, and Company auto-populate from the contact record and can be edited. Edits apply to the registration only, not the database. If not logged in, the user logs in or creates an account first.
If the contact's company is not a member/prospect, a Prospect record is auto-created with Prospect Level = Hot, Company Status = Active, and Prospect Source Type = "Event Web Registration."
✍️ Portal Registration Step 3: Attendee Details & Custom Fields
A summary of selected options appears at the top. Below that, for each ticket option, an expandable section allows attendee entry. Custom fields specific to each ticket display inline. The first attendee auto-populates with the registrant's info (editable). Remaining attendees default to "Reserved Attendee" if not entered. All fields except Additional Info are required for the first attendee.
Each ticket option creates a separate registration record. So if you buy Ticket A and Ticket B, you get two registrations.
💼 My Events: Post-Registration Management
Portal users with admin (Level 3) permission can view their registered events in the "My Events" section. The section shows registered events with ticket type and a "Manage Attendee Info" option. Until the registration window closes, users can update attendee information (names, custom fields). After the window closes, edits are blocked.
This allows members to finalize attendee names (e.g., moving people from "Reserved Attendee" to actual names) without re-registering.
🎭 Portal Event Landing Page: Promotional Hub
When a portal user views an event, they see the event name, date(s), location (address or virtual link), and description (rich WYSIWYG content). A "Register" button drives the registration flow. Event descriptions can include columns, formatting, HTML, tables, links, and images, allowing chapters to create rich marketing content.
Glossary
Quick reference for key terms in the ABC Events module.
📖 Key Terminology
Attendee: A person actually attending the event. May be a registrant or an included person from a sponsor package. Appears once in the attendees list regardless of how many tickets they hold.
Cart Item: A ticket held in a shopping cart before checkout. Does not create a registration until checkout is complete. Capacity is rechecked at checkout time.
Chapter Staff: Primary system users who manage event lifecycle, registrations, payments, and reporting. Requires Level 2+ with Events Permission to create/edit events.
Custom Field: A ticket-specific attribute collected from attendees during registration (e.g., meal preference, shirt size). Must be added before registrations occur.
Event: A single or multi-day occurrence (social/educational, in-person/virtual/hybrid, recurring/one-time) created by chapters for their members.
Event Classification: A category assigned to events for filtering and organization in the portal.
Function: An activity or component within an event (e.g., Dinner, Keynote, Workshop). Optional; events can exist without functions.
Included Items: Tickets bundled with another ticket (primarily sponsor packages). Auto-decrement capacity and auto-populate custom fields.
Invoice: A document generated for payment collection. Auto-created on Request Invoice or Pay Now. Also created as $0 invoices for free events.
Max Available: Ticket capacity limit. When blank, unlimited. When set, portal shows "Sold Out" once reached. Enforced in both portal and admin interface.
Member: A company with active ABC membership. Members see discounted pricing in the portal.
My Events: Portal section where authenticated users view registered events and update attendee info until the registration window closes.
Non-Member: A person or company without ABC membership. Sees higher pricing in the portal.
Payee: The individual or company responsible for payment on a registration or sponsor record.
Portal: Member-facing web interface for browsing events, registering, and managing registrations.
Prospect: A company not yet a member but interested in ABC. Auto-created when a non-member registers for an event (Level = Hot, Status = Active, Source = "Event Web Registration").
Registrant: The person who completes the registration process for a ticket.
Registration (Process): The workflow for signing up (Steps 1–4: contact info, ticket selection, attendee details, payment).
Registration (Record): A distinct data record created per ticket option selected. Multiple tickets = multiple registrations per person.
Reserved Attendee: A placeholder name for attendee spots not yet assigned to a specific individual. Can be updated later by staff or by the member in My Events.
Sponsor: A company providing financial/in-kind support to an event, typically purchasing a sponsorship ticket with included items.
Sponsor Attendee: An attendee included in a sponsor package. Primary attendee defaults to sponsor's info; additional attendees default to "Reserved Attendee."
Sponsor Ticket: A special ticket type for sponsorships. Can include multiple attendees and bundle other tickets as included items.
Table/Team Ticket: A group ticket type. Quantity = number of tables/teams. Supports "Attendees Per Table" rules (e.g., 8 people per table).
Ticket: An optional ticket tied to an event function with defined pricing (member/non-member/other). Has capacity, custom fields, and optional inclusion in bundled packages.
Ticket Type: Category (single ticket, table/team ticket, or sponsor ticket) determining pricing and attendee rules.
Test Strategy
Testing approach, priority areas, regression strategy, test data needs
Business Rules & Gotchas
Critical validation rules, edge cases, and system behavior you must understand for comprehensive testing
Functions & Tickets
Ticket type edge cases, max available capacity, custom fields timing, included items, badges
Coupon & Discounts
Coupon validation edge cases, scope testing, usage limits, one-time-per-user, expiration, manual discounts
Scenario Thinking
Cross-functional scenarios, what-if analysis, and integration testing patterns
Regression Checklists
Organized by feature area to ensure complete coverage across all modules
Environment & Data Setup
Test environment configuration and data prerequisites for comprehensive testing