Business Model — Event Hierarchy & Value Prop
The Core Idea: Events are activities (golf tournaments, conferences, dinners) that Chapters run to build community and generate revenue. Members (companies) register for events, buy tickets, pay online or via invoice, and attend. Every feature in this module exists to make registration painless, payment flexible, and reporting clear.
Event Hierarchy
Event
├── Location (physical or virtual)
├── Functions (activities within an event)
│ └── Tickets (pricing options, optionally tied to functions)
│ └── Custom Fields (attendee-specific data collection)
├── Registrations (individual ticket purchases → separate records)
├── Sponsors (company-level sponsorships with included items)
├── Attendees (actual people attending)
├── Invoices (financial records for all transactions)
└── Communications (customizable emails per event)
The Value Proposition
Why events matter to ABC, why they're critical to test, and what QA should care about.
Single Portal Real-Time Data AMS Integration Adoption DriverFor Members
- One portal for events + all other ABC business (no fragmented systems)
- Browse, register, pay all in one place
- See all their event history and upcoming events
For Chapters
- AMS data tied directly to events — no manual entry of registration data elsewhere
- Real-time registration numbers and payment tracking
- Better than third-party platforms like GrowthZone (the bar is high)
For National
- Uniform event data access across all chapters
- Reporting on member engagement and participation
- Data consistency (no more "which event system is the source of truth?")
QA Mindset
- Events are adoption-critical — if registration UX is clunky, chapters will leave
- Test the end-to-end flow (portal browse → register → pay) like a real member would
- Every integration point (member lookup, payment, invoice) must be smooth
Key Actors & Permissions
Who uses this system and what can they do at each permission level?
Level 0: Restricted Level 1: View Level 2: Add/Edit Level 3: AdminChapter Staff
- Level 1+: Can view events, functions, tickets, registrations
- Level 2+: Can create, edit, delete events, functions, tickets (with constraints)
- Level 3: Can manage event invoices (mark paid, send invoices)
- Can add registrations and process payments in the Chapter Site (including phone registrations)
Portal Users (Members)
- Browse events without login
- View event details without login
- Must authenticate to register
- Level 3 portal permission: Can manage attendee info after registration
Public Users (Non-Members)
- Can browse and view event details without logging in
- Must authenticate to register (no guest checkout)
- If company doesn't exist, auto-created as prospect (Prospect Source Type = "Event Web Registration")
QA Considerations
- Test that Level 2 users can't manage invoices (Level 3 only)
- Verify Level 1 users can't modify events
- Test non-member registration and prospect auto-creation
- Confirm no guest checkout — authentication always required
Critical Concept: Registration Records
This is THE most important idea to understand about Events. Get this wrong and your test coverage will miss whole categories of bugs.
One Ticket = One Record Attendee Separate Table/Team SplitsThe Rule
- Each ticket option selected = ONE separate registration record
- If an attendee buys golf + dinner + cocktail hour, that's 3 registration records
- Each registration record tracks: individual, company, ticket, price, quantity, status, payment info, etc.
- This enables individual tracking, status management, and cancellation of specific components
Registration vs. Attendee
- Registration: Data record of a ticket purchase (price, date, payment status)
- Attendee: The actual person who will attend (name, company, contact info, custom field data)
- Multiple registrations can point to the same attendee (if they buy multiple tickets)
- One registration can have multiple attendees (e.g., table of 8 people on a single table ticket purchase)
QA Mindset
- When testing registration, always think: "Is this rule being respected?"
- Test bulk status updates — changing 3 registrations to "Paid" should only affect those 3, not the attendee record
- Test deletion rules — can only delete registrations with "open" payment status
- When adding attendees during registration flow, verify they're getting properly linked to registration records
Events & Locations — BREAD Operations
Business Purpose: Events are the top-level container. Before anything else (functions, tickets, registrations), the event and its location must exist. This is foundational BREAD functionality: Browse, Read, Edit, Add, Delete. Get this right first.
Creating & Editing Events
Required FieldsWhat fields are required, what's optional, and what happens when you save?
Event Name Start Date End Date StatusRequired Fields
- Event Name — text field, unique per chapter
- Start Date — must be populated, defaults to today
- Event Status — defaults to Active
Optional Fields
- End Date — defaults to Start Date if not set
- Start Time / End Time — times within the date range
- Staff Contact, Classification, Sub Classification, Chapter Region
- Speaker / Instructor, Room Number, Max Registrants
- Memo fields (General Event, Confirmation, Invoice) — text areas with WYSIWYG
- Event Description — WYSIWYG with columns, formatting, HTML, tables, links, images (renders on Event Landing Page)
- Enable Registration checkbox — controls portal availability
- Registration Start/End dates — when "Register Now" appears (portal only; Chapter Staff can always change)
- Allow Invoice Requests checkbox — per-event override of chapter-level setting
- Event Reconciled with Accounting checkbox
QA Considerations
- Verify required fields are enforced before save
- Test auto-defaults (End Date = Start Date, Status = Active)
- Verify WYSIWYG description renders correctly on Event Landing Page
- Test registration dates only control portal access, not Chapter Site access
- Verify Allow Invoice Requests override works and has proper default
- Test change history is recorded for edits
Locations — Physical, Virtual & Company
Locations can be reused across events. Three types with different fields.
Physical Location Virtual (Link) Company LocationLocation Fields
- Location Name — required
- Status (Active/Inactive) — only active locations appear in selection lists
- Street Address, Main Phone, Directions — optional, appear on confirmations
- Contact (individual record from Individuals table) — optional, for company locations
- Notes — internal use only
Location Types & Creation Flow
- Physical: Standard location with address and contact
- Virtual: Event meeting link (for online events)
- Company: Member or prospect company location with individual contact from that company
- Locations created during event creation OR managed separately and reused
QA Considerations
- Test that inactive locations don't appear in dropdowns during event creation
- Test reusing a location across multiple events
- Verify directions appear on event confirmations
- Test company location contact field — should only show individuals from selected company
- Verify virtual event link persists and is editable
Delete Rules & Event Copying
When can events be deleted? What gets copied when you copy an event?
No Registrations Full Copy Date AdjustmentDeletion Rules
- An event can ONLY be deleted if there are NO registrations
- Delete button only shows if eligible (upper right corner of Event record)
- Delete confirmation is required
- Attempting to delete an event with registrations shows an error
Copying Events
- Available on View Event screen
- Copies ALL event information: event details, functions, tickets, custom fields, pricing
- Options when copying:
- Copy registrants: yes or no (default = no)
- Set new event start/end date and time
- Per function: set new start/end date and time
- System auto-calculates new function dates based on date offset
- All events can be copied regardless of whether they've occurred
QA Considerations
- Test deletion blockers — add one registration and verify delete button disappears/error shows
- Test copy with registrants (if copying a completed event)
- Test copy with date change — verify functions adjust correctly based on offset
- Copy an event multiple times and verify unique event records are created
- Verify custom fields are copied with the event
Company Profile — Events Tab
Quick view of events a company has attended or registered for.
Attendee List Company HistoryEvents Tab on Company Record
- Shows table of all events related to that company
- Columns: Event Name, Start Date, End Date
- Action: View Attendees (modal with list of attendees from that company for each event)
QA Considerations
- Verify only events with registrations from that company appear
- Test View Attendees modal — should show all attendee names from registrations
- Verify filtering works correctly if company has many events
Functions & Tickets — Pricing & Options
Business Purpose: Functions are activities within an event. Tickets are pricing options (single, table, sponsor) with member/non-member pricing. Custom fields collect attendee-specific data (handicap, entree choice, t-shirt size). This is where event structure gets granular.
Functions — Activities Within Events
Per EventFunctions are activities (golf, dinner, sessions) within an event with separate dates and locations.
Function Name Start/End Date Location SpeakerKey Business Rules
- Function Name — required text field
- Start/End Date/Time — default to Event date/time but can be changed independently
- Location — defaults to Event location but can be changed
- Speaker — optional text field (no auto-population from Event)
- Function dates are completely independent from overall Event dates
Delete Rules
- Functions can only be deleted if there are NO registrations for the function
- Delete confirmation required
QA Considerations
- Test creating a function with dates outside the event date range
- Test changing function location independently from event location
- Test deletion blocker — add registration for a function and verify delete fails
- Test Browse Functions table columns and sorting
Ticket Types & Pricing
Per EventTickets are pricing options: single, table, or sponsor. Each has member/non-member/other pricing.
Single Ticket Table/Team Sponsor Pricing TiersTicket Type Options
- Single Ticket: One person per ticket purchase
- Table/Team Ticket: Multiple attendees per ticket (e.g., 8 people at a table). Field: "Attendees Per Table/Team"
- Sponsor Ticket: Company-level sponsorship with optional individual contact. Can include other tickets as bundled items
Pricing Structure
- Member Pricing — for member companies
- Non-Member Pricing — for non-member companies
- Other Pricing — optional, with custom description field (e.g., "Student", "Government")
- Tax % — for taxable items (physical goods, swag)
- Include $0 on Invoice — flag for complimentary items
- Max Available — blank = unlimited; once reached, ticket no longer displayed for registration
- Access/Availability — Members only, Non-members, Staff Only
QA Considerations
- Test max available counter — purchase tickets and verify it decrements
- Test that Staff Only tickets don't appear on portal
- Test member vs. non-member pricing in portal registration flow
- Test Other pricing selection and custom description display
- Verify tax calculation on invoices
- Test Include $0 on Invoice flag for complimentary tickets
Tickets: Functions, Included Items & Custom Fields
Tickets can relate to functions and bundle other tickets (sponsors). Custom fields gather attendee data.
Function Relations Included Items Custom FieldsFunction Relations
- Tickets optionally relate to zero, one, or more functions
- Simple checklist of functions during ticket creation
- Tickets are NOT required to relate to functions
Included Items (Sponsor Bundles)
- Sponsor tickets can include other tickets with specified quantities
- Example: Sponsor package includes 2 golf tickets + 2 dinner tickets
- Included items decrement max available counter of bundled tickets
- Custom fields from included items are pulled in for sponsor attendees
Custom Fields for Tickets
- Add/Edit/Delete custom fields specific to a ticket
- Fields can be: text input or selection (with defined options)
- Add to Registration checkbox: If checked, field appears during portal registration. If unchecked, staff must gather data manually
- Warning: Editing a custom field that's "Add to Registration" AND has existing registrations triggers a warning about data discrepancy
- Fields can only be deleted if there are no registrations for that ticket
- To capture custom field info during registration, fields must be added BEFORE registration
- Manage Attendees per custom field — add/remove attendees, edit field values per attendee
QA Considerations
- Test function relations — verify checkboxes work correctly
- Test sponsor included items — verify they decrement the bundled ticket's max available
- Test custom field types (text vs. selection) during portal registration
- Test the warning when editing a custom field with existing registrations
- Test deletion blocker for custom fields with registrations
- Test "Manage Attendees" — adding/removing and editing per-attendee values
Copy Ticket & Badge Printing
Duplicate tickets with all settings. Print badges for attendees with custom formatting.
Copy Ticket Badge Config Badge PrintCopy Ticket
- Creates a new ticket with default name: "[ticket name] - copy"
- All ticket data INCLUDING custom fields copied to new ticket
- New ticket can be renamed and modified independently
Badge Configuration
- Badge stock: 10 per card, 8 per card, 6 per card, 8 per sticky label
- Badge format sort: Company or Individual
- Include: Name, City/State, Member Since
- Include custom field value — select which custom field to display
- Print [input value] on prospect badges — custom text for non-member badges
- Add sponsor logo — include company logo on badge
Badge Print Flow
- Browse/select registered attendees with filters: Company, Individual, Ticket, Custom Field
- Columns: Checkbox, Company, Individual, Registration Status, Ticket, Custom Field Value
- Select attendees to print, configure badge, generate PDF
QA Considerations
- Test copy ticket — verify all fields copy including custom fields
- Test badge configuration options and PDF layout
- Test badge filters and attendee selection
- Verify sponsor logos appear on badges when selected
- Test badge printing with different stock sizes
Registrations & Sponsors — The Core Data
Business Purpose: Registrations are individual ticket purchases (one per ticket option). Sponsors are company-level sponsorships with included items. Both create attendee records and payment invoices. This is where event data lives.
Browse & Filter Registrations
View TabView all registrations for an event with powerful filtering and detailed columns.
Status Filters Detailed Columns Bulk ActionsFilters Available
- Status: Open, Not Attending, Paid, Comped, All
- Function, Member/Non-Member, Company, Individual
Columns Displayed
- Company, Individual (defaults to "reserved attendee" if not entered), Registration Date, Status
- Payee, Paid Date, Paid Type, Ticket Name, Ticket Price, Tax, Quantity, Total Price
- Includes (bundled ticket names), Included In (parent ticket name)
- Region, Web Registered (Yes/No), Invoice #
Actions Per Registration
- Edit Registration, Custom Fields, Update Status, Mark Paid
- Mark Not Attending (excludes associated custom field data)
- Delete Registration (only if payment status is "open")
QA Considerations
- Test all filters independently and in combination
- Verify column data matches registration records
- Test Edit, Custom Fields, Update Status, Mark Paid, Mark Not Attending, Delete actions
- Verify delete is only available for open registrations
- Test Web Registered flag (should be Yes for portal registrations)
Add & Edit Registrations
Register individuals with full payment tracking and custom field data capture.
Keep Company Individual Auto-Update Payment InfoRegistrant Information
- Keep Company checkbox: Efficiency feature — pre-fills company on next registration
- Individual — type-ahead with option to add new individual
- Company — type-ahead with option to add new company (created as prospect)
- Informal Name, Email, Phone/Ext, Mobile, Title — optional fields
Auto-Update Rule (Critical)
- If individual selected via type-ahead AND new email/phone/mobile entered, auto-adds to individual record
- If Title changed, auto-updates individual record
- Test this carefully: Registration changes can auto-modify individual records
Ticket & Payment
- Select Ticket → Description, Price, Tax, Quantity, Total auto-fill
- Payee Type (default = Company), Payee Company, Payee Individual
- Payment Status, Payment Type, Reg Paid Date
- PO Number, Registration Source (defaults to "online" if from portal), Note
QA Considerations
- Test Keep Company checkbox — should pre-fill on next registration
- Test individual auto-update rule with email, phone, and title changes
- Test adding new individual and new company during registration
- Test auto-fill of ticket fields
- Verify payment info is captured correctly
Sponsors — Company-Level Sponsorships
Sponsorship records with included tickets and custom fields.
Sponsor Ticket Sponsor Logo Included ItemsAdd & Edit Sponsors
- Company — required, type-ahead with option to add new
- Individual — optional, type-ahead
- Email, Phone, Mobile, Title
- Sponsor Logo — upload new OR select from company's existing logos
- Ticket — Sponsor Ticket (description, price, tax, quantity auto-fill)
- Payment info — same structure as registrations
Browse Sponsors
- Filters: Open Sponsors, Paid Sponsors, Sponsor Ticket, Company
- Columns: Company, Individual, Registration Date, Status, Payee, Paid Date, Paid Type, Sponsor Ticket, Price, Tax, Total
- Includes, Web Registered, Invoice #
- Actions: Add, Edit, Custom Fields, Delete
Delete Rule
- Sponsors can only be deleted if: status is open AND no invoice attached AND no individual registered as attendee
QA Considerations
- Test sponsor creation with and without individual contact
- Test sponsor logo upload and selection
- Test sponsor custom fields based on sponsor ticket and included items
- Test delete blocker — verify deletion fails when conditions aren't met
- Verify included items are tracked correctly
Attendees & Centralized View
Centralized view of ALL event attendees, unique per person, with edit capabilities.
Unique Attendees Bulk Edit ExportAttendees Tab — Key Rules
- An attendee should only show ONCE in the table (even with multiple tickets)
- Filters: Company, Status, Ticket, Sponsor Attendee (Yes/No), Attendee Name
- Columns: First Name, Last Name (shows "Reserved Attendee" if not entered), Email, Company (with Company Status)
- Payment Status, Tickets (all tickets for the attendee), Sponsor Attendee flag, Additional Information
Actions
- Edit — modal to edit all fields available during registration
- Mark Not Attending — excludes ALL associated custom field data based on attendee's tickets
- Export to Excel — respects applied filters
QA Considerations
- Test that attendee appears only once even with multiple tickets
- Test filters independently and in combination
- Test Edit modal — verify changes persist
- Test Mark Not Attending — verify custom fields are cleared
- Test Export respects filters
Portal Experience — Public Browse & Registration
Business Purpose: Members and non-members discover and register for events through a public portal without needing to contact chapter staff. This is a critical adoption driver — the portal UX must match or exceed third-party platforms like GrowthZone.
Browse Events — 3 Views
Public AccessUsers can browse upcoming events in three different views, with search and filters.
List View Grid View Calendar ViewView Types
- List View: Linear display with Name, Description, Date, Time, Location
- Grid View: Card-based layout with same info per card
- Calendar View: Full calendar with month navigation, click to see details
- Users can switch between all three views dynamically
Event Display Rules
- Only current and upcoming events displayed (not past events)
- Full-text search across event names and descriptions
- Filters: Location (dropdown), Event Classification (dropdown showing only applicable classifications)
- No login required to browse
Default View Configuration
- Chapter setting in Manage Portal Settings
- Options: List, Grid, or Calendar
- Users can still switch views after landing
QA Considerations
- Test all three view types — verify display and usability
- Test search across event names and descriptions
- Test location and classification filters
- Test calendar view date navigation and click-to-view behavior
- Verify past events don't display
- Test default view configuration per chapter
Event Landing Page & Registration Flow
Portal Steps 1–4Event details display. 4-step registration: Contact → Tickets → Info → Payment.
Event Details Step 1: Contact Step 2: Tickets Step 3: Info Step 4: PaymentEvent Landing Page
- Displays: Event Name, Event Date(s), Event Description (WYSIWYG rendered), Event Address
- "Register" button (controlled by registration dates and Enable Registration checkbox)
- Description with formatted content, images, links
Step 1: Contact Information
- If logged in: Auto-populate email, first name, last name, company (editable for this transaction only)
- If NOT logged in: Email field + Search button. If found, auto-populate remaining fields
- Authentication options: Log in OR Create new account (NO guest checkout, email verification required)
- Prospect creation rule: If contact's company not member and not already prospect, created as prospect (LOI=Hot, Status=Active, Prospect Source Type="Event Web Registration")
Step 2: Select Ticket Options
- Each ticket displays: Name, Description, Price, Included Attendees count, Available Spots
- Available Spots = Max Available - Number Purchased (or "Unlimited" if no max)
- Users adjust quantity with UI control (spinner or input)
- If sponsor ticket includes other tickets, those are counted against max available
Step 3: Registration Information
- Summary table: Ticket, Price, Quantity, Attendees, Subtotal, with expansion for included items. Total row.
- Attendee sections (expandable/collapsible) organized by ticket option
- Per attendee: type-ahead contact search, First Name, Last Name, Email, Company, Additional Information (custom fields)
- First attendee per ticket: all fields required except Additional Info. Auto-filled with registrant info (editable)
- Other attendees: optional fields. Defaults to "reserved attendee" if not entered (editable later)
Sponsor-Specific Rules
- "Sponsor" section above attendee sections with sponsor info (ALL required except Additional Info)
- Sponsor logo: select existing OR upload new
- Included tickets decrement remaining available count
- Individual attendees from sponsorship appear in registrations with $0 value
QA Considerations
- Test Step 1 login and create account flows thoroughly
- Test prospect auto-creation with non-member registration
- Test Step 2 ticket display and availability counter decrement
- Test Step 3 attendee info auto-fill and optional field handling
- Test sponsor sections and included item decrement
- Test "reserved attendee" default behavior
Step 4: Payment Options
Three payment paths: Pay Now, Add to Cart, Request Invoice.
Pay Now Add to Cart Request InvoiceThree Payment Options
- Pay Now: Bypass cart, pay immediately (only current registration, not other cart items). Uses existing payment gateway (CC/ACH).
- Add to Cart: Add to shopping cart for later payment (supports multiple event registrations across events)
- Request Invoice: Complete registration, generate unpaid invoice for later payment. Due date from Event Details "Requested Invoice Due Date" field
Shopping Cart Rules
- Cart items show: Ticket Name, Price, Included Attendees, Included Items, Quantity, Subtotal. Remove option.
- Order summary with subtotal and total
- "Proceed to Checkout" → payment screen (CC/ACH options)
- Cart items do NOT create registrations until checkout is completed
- If event capacity fills while items in cart, checkout will fail for unavailable events
QA Considerations
- Test Pay Now flow end-to-end
- Test Add to Cart with multiple events
- Test cart persistence over time (session handling)
- Test Request Invoice flow and invoice generation
- Test that cart items don't create registrations until checkout
- Test capacity fill scenario — checkout should fail gracefully
- Test payment gateway integration (CC, ACH)
My Events & Manage Attendee Info
Portal users can view their registered events and manage attendee information.
Upcoming + Past Manage Attendees Level 3 PortalMy Events
- Navigation: Events → Upcoming Events (browse) + My Events
- Shows upcoming and past events the user has registered for
- Columns: Event Name, Start Date/Time, End Date/Time, Location Name
- Action: View Details (same as Event Landing Page + Manage Attendee Info button)
Manage Attendee Info
- Available from View Details screen in My Events
- Interface similar to Step 3 of registration flow
- Update attendee info for all registered attendees
- Requires Level 3 portal permission
- Only available until registration closes
QA Considerations
- Test My Events display accuracy
- Test Manage Attendee Info interface
- Test permission enforcement (Level 3 only)
- Test registration close date boundary — button should disappear after
- Test that changes to attendee info persist
Payments & Invoices — Financial Tracking
Business Purpose: Events generate invoices for registrations and sponsorships. Chapter staff and members can process payments online or offline. Invoices are generated automatically for cart checkout and invoice requests, and manually for chapter staff actions.
Payment Processing Paths
Where payments come from and how they're processed in the system.
Portal Pay Now Cart Checkout Chapter Site Manual Offline Payment RecordingPayment Sources
- Portal Pay Now: Credit Card (via Authorize.net or chapter-specified gateway) and ACH. Paid immediately.
- Cart Checkout: Same CC/ACH options. Pays for all cart items at once.
- Chapter Site Manual Registration: Staff collects payment during Add/Edit Registration. Supports: Credit Card, Check, Cash.
- Invoice Payment (Portal or Email): Later payment on unpaid invoices via portal or no-login payment link.
Payment Recording
- Portal payments auto-recorded with Paid Date = current date, Payment Type = gateway type
- Chapter staff can manually record payments from View Invoice screen
- Registration Status updated to Paid when payment received
- Payee, Payment Date, and Payment Type updated
QA Considerations
- Test each payment path end-to-end
- Test payment recording and registration status update
- Test gateway integration (CC, ACH, check/cash entry)
- Verify payment date is recorded correctly
Invoice Generation & Rules
When invoices are created, what's on them, and how they're tracked.
Auto-Generation $0 Invoices Invoice StructureInvoice Generation Triggers
- "Request Invoice" portal option: Auto-generates unpaid invoice at registration completion
- Cart checkout: Auto-generates paid invoice after payment confirmed
- Pay Now: Auto-generates paid invoice after payment confirmed
- Chapter staff manual payment: Auto-generates paid invoice when staff records payment
Invoice Rules
- $0 invoices created for free events (for reporting consistency)
- All paid transactions generate invoices marked as "paid" for historical records
- Unpaid invoices from "Request Invoice" have due date from Event Details "Requested Invoice Due Date"
- Each registration/sponsor record can have one invoice OR be tied to a cart invoice
Invoice Contents
- Registration details: Individual, Company, Ticket Name, Quantity, Unit Price, Tax, Total
- Event details: Event Name, Date, Location (for context)
- Payment info: Invoice #, Invoice Date, Due Date, Payment Status
- Memos and custom text from event configuration
QA Considerations
- Test invoice generation for each trigger (Request Invoice, Pay Now, Cart, Manual)
- Test $0 invoice creation for free events
- Verify invoice content accuracy (all registrations, correct totals)
- Verify unpaid invoice due dates match Event Details setting
- Test invoice status transitions (Open → Paid)
Browse Event Invoices
Module & Event LevelView and manage invoices at module level or per event.
Module Level Event Level Bulk SendModule Level: Browse Event Invoices
- Navigation: Events module → Browse Event Invoices (across ALL events)
- Permissions: Level 3 can manage; Level 1-2 can view/filter
- Filters: Member/Non-Member, Company, Event, Status, Payment Date Range
- Columns: Checkbox, Invoice #, Invoice Date, Company Name, Event Name, Event Start Date, Registrant Name, Invoice Amount, Payment Status, Payment Date, Payment Method, Due Date
- Actions: Send Unpaid Invoice Email (bulk to selected), Click Invoice # to view/edit
Event Level: Invoices Tab
- Invoices tab on Event record
- Same structure as module level, minus Event Name/Start Date columns
- Same permissions, filters, columns, and actions
QA Considerations
- Test all filters independently and in combination
- Test column accuracy and sorting
- Test bulk Send Unpaid Invoice Email action
- Test click-to-view invoice and manual payment recording
- Verify permission enforcement
Invoice Request Settings
Configure whether members can request invoices during portal registration.
Chapter-Level Setting Event-Level OverrideConfiguration
- Chapter-level: "Allow invoice requests during portal event registration" in Manage Portal Settings (default = unchecked, not allowed)
- Event-level: Same checkbox on Event Details tab. Defaults to chapter setting but can be changed per event.
- If disabled, "Request Invoice" button doesn't appear on Step 4 of portal registration
QA Considerations
- Test chapter-level setting — should affect all events using default
- Test event-level override — verify it can be different from chapter setting
- Verify "Request Invoice" button appears/disappears based on setting
Coupons & Discounts — Promotional Tools
Business Purpose: Chapters can create coupon codes to incentivize registration and offer bulk discounts. Coupons are scoped to events or specific tickets. They apply via portal with real-time validation and can be manually applied by chapter staff.
Coupon Code Setup
ConfigurationCreate coupon codes with flexible discount types, scope, and usage rules.
Coupon Code Discount Type Event Scope Usage LimitsNavigation & Permissions
- "Event Coupon Codes" menu option in Events module
- View/manage ability added to existing Events permission set
Browse Coupon Codes
- Columns: Coupon Name, Coupon Code, Discount Type (Percentage/Dollar Amount), Discount Value, Usage Count / Max Usage, Expiration Date, Event Scope (All Events/Selected Events/Selected Event Ticket), Status (Active/Inactive/Expired)
- Actions: Add, Edit
Add & Edit Coupon Codes
- Coupon Code — alphanumeric, unique per chapter
- Coupon Name — descriptive name for internal reference
- Discount Type — Percentage OR Fixed Dollar Amount
- Discount Value — numeric
- Event Scope:
- All Events — applies to any event registration
- Selected Events — multi-select list of events
- Selected Event Tickets — select event first, then multi-select specific tickets
- Usage Limitations:
- Max Usage Count — blank = unlimited
- One-time use per user — checkbox
- Expiration Date — optional, auto-transitions to "Expired" status when passed
- Status — Active or Inactive (default = Active)
QA Considerations
- Test coupon code uniqueness
- Test discount type calculations (% and fixed $)
- Test event scope options and multi-select
- Test usage limit enforcement
- Test one-time-per-user flag
- Test expiration date auto-transition to Expired status
Portal Coupon Application
Users apply coupon codes during portal checkout with real-time validation.
Real-Time Validation Immediate Calculation RemovalApplication Flow
- Text input field with "Apply" button during checkout (Step 4)
- Real-time validation: Immediate check on entry
- Error messages: invalid code, expired code, usage exceeded, scope doesn't match
- Success confirmation with discount amount
- Price display: original price, discount amount, final price
- Total updates immediately after application
Coupon Removal
- Users can remove coupon before checkout completion
- Total reverts to original price
Authentication Requirement
- Non-member users must be logged in to apply coupon codes
- Member users logged in can apply coupons
QA Considerations
- Test coupon application with valid codes
- Test error messages (invalid, expired, exceeded, scope mismatch)
- Test real-time validation and price calculation
- Test coupon removal and price reversion
- Test non-member login requirement for coupon application
- Test one-time-per-user enforcement
Chapter Site Manual Discounts
Staff can apply discounts directly when adding/editing registrations.
Discount Type Discount Value TrackingManual Discount Fields
- On Add/Edit Registration screen
- Discount Type Selection — Percentage / Fixed Dollar Amount
- Discount Value Input — numeric
- Discount Reason/Notes — optional, for internal tracking
- Auto-calculation of discounted price
- Original ticket price preserved for reporting
- Staff user who applied discount is tracked
QA Considerations
- Test discount type calculations
- Test that original price is preserved (for reporting)
- Test that staff user is tracked
- Test discount reason/notes capture
Discount Tracking & Reporting
Discounts are tracked on registrations for auditing and reporting.
Coupon vs Manual ReportingRegistration Columns
- Price (existing) — original ticket price
- Discount Applied — "Coupon Code" or "Manual Discount" (or none)
- Discount Amount — $ value of discount
- Discounted Price — final price after discount
Coupon Code Usage Reporting
- Leverages Metabase (reporting tool)
- Available data: Total Usage Count, Total Revenue Impact, Usage by Event, Member vs. Non-Member Breakdown, Usage Timeline
QA Considerations
- Test discount tracking on registration records
- Verify Coupon Code vs. Manual Discount distinction
- Test discount amount and discounted price calculations
- Test Metabase reports if accessible
Communications — Event Emails
Business Purpose: Chapters customize three event-specific emails: Unpaid Invoice reminders, Registration Confirmations, and Payment Confirmations. These emails are configured per event (not on a global "Manage Application Emails" screen) and are triggered by specific actions.
Communications Tab Setup
Per EventConfigure three customizable emails directly on the event record.
Event-Level Config Not Global Three Email TypesConfiguration Location
- Communications Tab on Event record
- NOT on the Manage Application Emails screen — this is event-specific only
- Each event can have different email templates
Three Customizable Emails
- 1. Unpaid Event Invoice: Triggered manually by staff (bulk send option available)
- 2. Event Registration Confirmation: Triggered when portal user completes registration (Step 4)
- 3. Event Payment Confirmation: Triggered when registrant completes payment:
- Pay Now (Step 4)
- Cart checkout
- Invoice payment later (portal or offline)
- Note: Design question whether it triggers for chapter staff manual payments
QA Considerations
- Verify emails are configured per event, not globally
- Test all three email types are sent at correct triggers
- Test email content with merged fields (attendee names, ticket info, amounts)
- Test bulk send for unpaid invoices
- Test that different events can have different email templates
- Verify email formatting (text vs. HTML)
Email Triggers & Content
When emails are sent and what content they contain.
Triggers Merged Fields RecipientsUnpaid Invoice Email
- Trigger: Manual, sent by chapter staff (bulk send to multiple registrations)
- Recipients: Registrant email address
- Content: Invoice details, due date, payment instructions, link to pay online
Registration Confirmation Email
- Trigger: Automatic, immediately after portal registration completion (Step 4)
- Recipients: Registrant email address
- Content: Event details, attendee names, ticket info, amount (if paid), next steps
Payment Confirmation Email
- Trigger: Automatic, after payment received (Pay Now, Cart checkout, Invoice payment)
- Recipients: Registrant email address
- Content: Payment received, amount, invoice #, event details
Email Customization Fields
- Subject line
- Body (WYSIWYG with formatting)
- Merged fields available (event name, dates, attendee names, amounts, etc.)
- Footer/disclaimer text (optional)
QA Considerations
- Test each email trigger — verify emails send at correct moments
- Test merged fields — verify all placeholders resolve correctly
- Test email formatting (text vs. HTML) and rendering
- Test email delivery (check spam folder, delivery logs)
- Test bulk send of unpaid invoices with multiple recipients
- Test customization — create different templates per event and verify
Email Configuration Best Practices
How to think about testing event emails effectively.
Event-Specific Defaults ConsistencyKey Points for QA
- Per Event: Each event has its own email templates. Multiple events should have independent templates.
- Defaults: If no custom template configured, system may use a default or no email sent — clarify expected behavior
- Consistency: Test that email content matches event details (name, date, amount)
- Personalization: Verify merged fields are working correctly for different attendee/company combinations
Testing Approach
- Create test events with custom email templates
- Register, pay, request invoices, and verify correct emails are sent
- Test with multiple events to ensure isolation (one event's email doesn't affect another)
- Test with different attendee names, companies, and amounts to verify merged field accuracy
- Test bulk send scenarios (multiple unpaid invoices)
QA Considerations
- Create a test email account to capture all notifications
- Document email template configuration per event in test cases
- Verify no unexpected emails are sent
- Test with HTML and plain text email clients if applicable