The problem
Banner tells this university who a student is academically. MS Dynamics tells it who’s engaged — donors, alumni, prospective students, event attendees the advancement and admissions teams want to keep talking to. Registration activity through Swoogo is exactly the kind of signal Dynamics needs. Someone attended a webinar, showed up to an info session, registered for a fundraising gala. None of that reached Dynamics on its own.
The approach / solution
- Built a direct sync between this client’s Swoogo registration data and MS Dynamics, so event activity lands in the CRM as it happens.
- Reused the per-student custom field-mapping layer already in place for this client’s Banner sync (covered in a sibling case study), so the same registration record maps cleanly onto both the SIS and the CRM sides.
- Runs on the client’s own isolated PostgreSQL database, the same tenant database backing the Banner sync.
- Built against MS Dynamics’ own REST API. No manual export step anywhere in the pipeline.
Outcome / result
Registration activity from Swoogo now shows up inside Dynamics without anyone re-keying it. An attendee’s engagement history in the CRM stays current the same day a registration comes in, which is what actually makes it useful to an advancement or admissions team working from that data.
Why it matters for enterprise event-tech
Most Swoogo-CRM work stops at “the data eventually gets there.” Reusing one field-mapping layer across two entirely different downstream systems — an academic SIS and a CRM — on the same account is what a well-architected institutional integration actually looks like, versus building the mapping logic twice and hoping the two versions stay in sync with each other.
