Prerequisite Complete: Authentication & Roles System — role infrastructure, Pundit policies, and permission flag patterns are now available.
Recommendation: Lean Yes
Integration eliminates manual data prep, provides historical attendance tracking, and positions Alumni Lookup as the single source of truth for alumni engagement — including events.
| Category | Pros | Cons |
|---|---|---|
| Data model / IDs | Alumni Lookup already has BUID + contact_id (BQID). Direct matching eliminates Excel merge. New Contact model aligns with BruinQuest terminology. |
Need new Contact, Event, Registrant tables. Non-alumni attendees require careful handling (solved via Contact model). |
| Operational workflow | GiveCampus CSV → Alumni Lookup → Check-in → Export in one app. Persistent contact identity across events. | Staff must learn new UI. Badge printing integration requires testing with DYMO printers. |
| User experience | Single app for staff. No context switching. Consistent Tailwind/TailwindUI patterns. | alum-events has custom modal system (Picnic CSS); porting requires Tailwind adaptation. |
| Technical complexity | Same stack (Rails 7, PostgreSQL, Hotwire). Shared auth via Devise. | ~3-4 months additional dev work across phases. Badge template system needs Tailwind rewrite. |
| Testing / maintenance | One test suite, one deployment, one codebase. | Integration tests for check-in flows must be added. |
| Champion Portal | Event attendance data feeds into Champion engagement history. Future: champion-led event check-in. | If integration slips, could conflict with Portal timeline. Mitigate by treating as parallel track. |
| CRM alignment | Contact model matches BruinQuest terminology. Export includes all RSVPs for offline BQID assignment decisions. |
No automatic BQID creation — manual review required for new contacts. |
| Question | Decision / Notes |
|---|---|
| Who are the primary internal users for integrated event features? | Advancement Services, Alumni Engagement team, event volunteers |
| Do we need ALL alum-events features in v1? | No. Core v1: import, check-in, walk-ins, export. Defer: badge templates, photos, regrets, group flows to Phase 4. |
| How important is supporting non-alumni attendees inside Alumni Lookup? | Critical. Parents, guests, staff attend events. Contact model handles all types. |
| Should badge printing be integrated, or remain browser-based (Cmd+P)? | Keep browser-based print dialog + DYMO printers (proven pattern from alum-events). |
| Who decides if a non-BQID contact should be added to BruinQuest? | Offline decision by Advancement Services during post-event review of export CSV. |
| Question | Decision / Notes |
|---|---|
| How do we represent people who attend events? | Contact model — can be linked to Alumni or standalone for non-alumni. |
How does Contact relate to Alumni? |
Contact has optional belongs_to :alumni. For alumni-type contacts, link to existing Alumni record. |
| How should BQID be stored? | On Contact.bqid. For alumni-linked contacts, mirrors Alumni.contact_id. |
What’s the unique constraint on Contact? |
BQID (if present) OR combination of email + name for matching. |
| How do we handle walk-ins who are confirmed alumni? | Search Alumni Lookup, create Contact linked to Alumni, create Registrant. |
When importing a GiveCampus RSVP CSV, match in this priority order:
| Step | Match Criteria | Action |
|---|---|---|
| 1 | Existing Contact by BQID |
Use existing Contact |
| 2 | Existing Contact by name + email |
Use existing Contact |
| 3 | Existing Alumni by BQID (contact_id) or BUID |
Create Contact linked to Alumni |
| 4 | Existing Alumni by name + email |
Create Contact linked to Alumni |
| 5 | No match found | Create Contact as guest/unknown type |
| Question | Decision / Notes |
|---|---|
| Single Rails app or API integration? | Single app. Same database, same Devise auth, same deployment. |
| How will authentication work for event tools? | Internal staff use existing User model (Devise). Event-specific permissions (not just roles) for granular access control. |
| Session-scoped vs global “active event”? | Session-based (session[:active_event_id]) for concurrency — multiple stations can work different events. |
Event features use the application’s hybrid authorization model (Roles + Permission Flags) documented in PERMISSIONS_MATRIX.md. This approach supports:
| Permission Flag | Description | Who Gets It |
|---|---|---|
can_event_checkin |
Search registrants, check in, mark printed, view stats | Event volunteers, Staff, Admin |
can_event_manage |
Create/edit events, import CSV, export data, manage settings | Staff, Admin |
Why Permission Flags (not just roles)?
Event check-in is a cross-cutting feature — a volunteer with NO general Alumni Lookup access may need to check in attendees. This doesn’t fit cleanly into Staff/Admin roles, so we use permission flags.
Implementation: See docs/development/PERMISSIONS_MATRIX.md → “Hybrid Authorization Model” section for:
event_checkin for events in their region via cp_champions table permissions.Key Benefit: A user can have event_checkin permission WITHOUT having general Alumni Lookup access — perfect for event-day volunteers.
| Question | Decision / Notes |
|---|---|
| How should event attendance flow into engagement scoring? | Create EngagementActivity on check-in with activity_code: 'event_attendance', level 3. |
| Which reports depend on integrated event history? | “Attended last N events”, “Event attendance by college/year”, engagement dashboard filters. |
| Do we need real-time dashboards during events? | Nice-to-have for Phase 4+. Can add Turbo Streams for live check-in counts. |
Export everyone who RSVP’d, regardless of BQID status:
| Column | Description |
|---|---|
| BQID | Contact’s BQID (blank if not in BruinQuest) |
| BUID | Alumni’s BUID (blank if not alumni) |
| First Name | From Contact |
| Last Name | From Contact |
| From Contact | |
| Contact Type | alumni, parent, student, staff, guest, vip, unknown |
| Attendance | attended, regrets, noshow |
| Has BQID | Yes/No flag for easy filtering |
Offline workflow:
Has BQID = Yes → import attendance directly to BruinQuestHas BQID = No → manual review to decide: