The problem
This university runs its own internal Student Task Manager — assigned items tied to a student’s record, things like a document to submit or an orientation step to complete. A registration through Swoogo could trigger one of those tasks, or a task could already be sitting there waiting when a student showed up to register. Either way, the student had no way to see it without logging into a separate system entirely. A task a student doesn’t see is a task that doesn’t get done.
The approach / solution
- Built a backend connection pulling CRM-linked task data from this client’s Student Task Manager into the platform, so a registrant’s task list is available wherever the Swoogo side of the platform needs it.
- Registrants needed to actually see that list somewhere, in the moment, on the page they were already using. Swoogo’s page builder accepts only Twig templates, so the task-list widget got built directly inside Swoogo’s own templating system — checkboxes, due dates, and status all rendered right on the student’s event registration page.
- Runs on the client’s own isolated PostgreSQL database, one of five separate tenant databases on the platform.
Outcome / result
A student registering for an event on this client’s Swoogo account now sees their own assigned tasks in the same place, fed live from the university’s Student Task Manager. Nobody has to explain where else to go look for it.
Why it matters for enterprise event-tech
A lot of integration work stops at moving data between two backend systems and calling the job done. Here, the same team owned both halves — the backend feed from the Student Task Manager and the front-end surface where a student actually sees it. That’s the difference between data that technically synced somewhere and a feature a student experiences.
