alumni_lookup

Event Check-in Integration: Champion Portal Interaction

Prerequisite Complete: Both Event Check-in and Champion Portal depend on Auth & Roles System. The sequencing below assumes Auth & Roles is done.

How Integrated Event Data Enhances Champion Portal

Benefit	Description
Richer engagement insights	Champion profiles can display “Attended 5 events since 2022” based on real check-in data
Event history on profile	Champions see their own attendance history, reinforcing engagement
Future RSVP flows	Champion Portal Phase 2 plans champion-submitted events; integrated `Event` model provides the foundation
Champion-led check-in	Future feature: trusted champions could check in attendees at regional events via the Portal
Data consistency	Single `Event` model used by both internal staff and Champion Portal views — no sync required

Is Event Integration a Hard Dependency for Champion Portal v1?

No.

Champion Portal v1 (auth, profile, directory, regional structure, dashboard) does not require event check-in data. The Portal can ship using:

Existing EngagementActivity data (imported from CRM)
BUID linking to Alumni records for profile enrichment
Champion signup state from ChampionSignup

Event integration becomes valuable in Portal Phase 2 (Events, Stories, Mentorship), but even then, champion-submitted events are a separate flow from staff-managed check-in events.

Sequencing Strategy

Recommended Approach: Parallel Tracks

                    Auth & Roles        Month 1-3              Month 3-6              Month 6+
                    ────────────        ─────────              ─────────              ─────────
                    [Phases 1-6:        
                     Roles, SSO,        
                     Permissions]       
                         │              
                         ├──────────────────────────────────────────────────────────────────────
                         │              │                      │                      │
Champion Portal          │              [Phase 1: Auth,        [Portal v1 Launch]     [Phase 2: Events,
                         │               Profile, Directory]                           Stories]
                         │                   │                       │                     │
                         │                   │                       │                     │
Event Integration        │              [Phase 0-1: Planning,  [Phase 2-3: Import,    [Phase 4-5: Badges,
                         │               Data Model]            Check-in UI]           Portal Alignment]

Why This Works

Champion Portal v1 is the primary track — higher user-facing value, defines auth/profile patterns
Event Integration Phases 0-2 run in parallel — minimal UI work, doesn’t compete for same components
Phase 3 (Check-in UI) proceeds once Phase 2 is done, regardless of Portal status
Phase 5 (Portal alignment) waits for both Portal v1 and Phase 3 to be complete

Key Sequencing Decisions

Decision	Recommendation
Which ships first?	Champion Portal v1 (unless reunion season demands event features sooner)
Can they share dev effort?	Yes — Phase 1 data model work is backend-only, Portal is frontend-heavy
What blocks what?	Nothing blocks each other until Phase 5
When do they converge?	Phase 5 (Portal alignment) bridges event data into Champion-facing views

Detailed Interaction Points

Data Model Overlap

Model	Used By Staff Portal	Used By Champion Portal
`Alumni`	✅ Search, profiles	✅ Profile enrichment
`Contact`	✅ Event registrations	⏳ Phase 5 (attendance history)
`Event`	✅ Event management	⏳ Phase 5 (read-only history)
`Registrant`	✅ Check-in tracking	⏳ Phase 5 (read-only)
`EngagementActivity`	✅ Scoring, reports	✅ Dashboard metrics

Champion Portal Phase 2: Events

The Champion Portal roadmap (see docs/planning/champion-portal/) plans champion-submitted events in Phase 2:

Champion events = submitted by champions, approved by staff, posted to regional/national feeds
Staff events = managed via integrated check-in system

Question: Should these use the same Event model?

Recommendation: Yes, with differentiation:

class Event < ApplicationRecord
  enum event_source: {
    staff_managed: 'staff_managed',      # Traditional check-in events
    champion_submitted: 'champion_submitted'  # Future Portal events
  }
  
  belongs_to :submitted_by, class_name: 'Champion', optional: true
  # ... existing fields ...
end

This allows:

Single source of truth for all events
Staff events created via internal UI
Champion events created via Portal (with approval workflow)
Both types can have registrants and attendance tracking

Risks & Mitigations

Risk	Impact	Mitigation
Event integration scope creep delays Portal	Medium	Keep integration phases small; defer badges/photos to Phase 4
Two parallel tracks strain dev capacity	Medium	Prioritize Portal v1; event integration can slip until reunion season
Data model decisions conflict	Low	Finalize `Contact`/`Event`/`Registrant` schema in Phase 1 before Portal v2 event planning
Champion-led check-in requires new permissions	Low	Permission-based model (`event_checkin`) already planned; extend to CLC in Phase 5
`Contact` model confusion with existing `contact_id` field	Low	Clear naming: `Contact` (model) vs `contact_id` (BQID field on Alumni)

CLC Regional Check-in (Phase 5+)

City Leadership Council members may need to check in attendees at regional events. This requires:

Permission Model

Permission	Internal Users	CLC Members
`event_checkin`	Per-user flag on `users` table	Via `cp_champions` table or regional scope
`event_manage`	Per-user flag on `users` table	❌ Not available to CLC

Regional Scoping

CLC check-in should be limited to events in their region:

# Future: CLC can only check in at events in their region
class RegistrantPolicy
  def checkin?
    return true if user.can_event_checkin?  # Internal staff
    return true if user.admin?
    
    # CLC: check regional match
    if user.is_a?(Champion) && user.clc?
      event.region == user.region
    else
      false
    end
  end
end

Implementation Notes

CLC check-in access is read from Champion Portal auth, not internal users table
May need Event#region field for geographic scoping
Mobile-optimized check-in UI is critical for CLC use case (phone at regional events)

Open Questions for Future Discussion

Question	Context	When to Decide
Should champion-submitted events use the same `Event` model, or a separate `cp_events` table?	Affects data architecture	Before Portal Phase 2
Can champions see OTHER champions’ attendance history?	Privacy consideration	Portal Phase 5 planning
Will Advancement Services want attendance pushed to BruinQuest automatically (API)?	Currently CSV export only	After Phase 2 launches, based on feedback
Should CLC members be able to check in attendees at regional events?	Permissions/trust model	Portal Phase 2+
How do champion event RSVPs flow into registrant data?	Integration complexity	Portal Phase 2 planning
What defines an event’s “region” for CLC scoping?	Geographic model	Before CLC check-in implementation

Success Criteria for Integration

Phase 5 Complete When:

✅ Champions can view their event attendance history in Portal
✅ Event attendance contributes to engagement scoring visible in Portal dashboard
✅ Staff and champion event data use consistent models
✅ API endpoint exists for champion event history (if needed for Portal)
✅ Documentation updated with integration patterns

Future State (Portal Phase 2+):

⏳ Champions can submit events for approval
⏳ Regional events appear in champion feeds
⏳ RSVP functionality for champion-posted events
⏳ CLC-led check-in at regional events (with event_checkin permission)