Populi

Overview

Status: active build/deployment. Populi is TCR’s student information system (SIS) — the system of record for student data going forward, and part of the ground-up infrastructure build. It drives account provisioning: creating a Populi account generates access to Google Workspace and other relevant systems on onboarding, and Populi is the primary trigger for credential deactivation on offboarding.

Technology

Web-based, hosted and managed by Populi as a third-party service provider. Includes integrated payment processing (via Payfactory as the payment processor) — see the PCI DSS policy for how that’s scoped.

Not yet documented: specific plan/tier, exact hosting details beyond “third-party managed.”

Background & why

TCR has only recently moved to digital administrative systems at all. The SIS specifically went through three systems in succession:

1. Sonis (by Jenzabar)
2. Campus Cafe
3. Populi (current)

The first two were short-lived, and were chosen by non-technical people under survival pressure — decisions made to have something working, not with an eye toward what the college would need as it grew. Populi is the first SIS choice made with real intentionality, by a qualified technical person, evaluated for both TCR’s actual current use and its future growth rather than just getting something running.

This history is also why the Transcript App exists: it has to reconcile Populi data with legacy Jenzabar (Sonis) records, since academic history from before Populi didn’t come along for free.

Not yet documented: exact adoption date, and whether any Campus Cafe-era data was migrated or was lost/left behind.

Integrations

• Canvas: native integration (vendor-provided, not custom-built) — see Canvas.
• SQL Server: nightly n8n sync pulls students, terms, and term enrollments from the Populi API into TCR_StudentRecords on Daedalus, feeding the custom transcript app. See TCR Transcript App.
• Google Workspace: Populi account creation cascades into Google Workspace account provisioning.
• n8n: the applicant email lifecycle (submission, pending, provisional, confirmed) is managed through n8n; it’s not yet documented exactly how far upstream Populi is in triggering those stages versus another system.
• Payfactory / Adyen (payments): see PCI DSS policy.
• Custom Student Dashboard: students authenticate via Populi SSO, which also gives TCR user management and monitoring.

API notes

The nightly sync pulls against Populi API2, and the workflow is shaped by real constraints discovered building it:

• Rate limit: 50 requests/minute during daytime hours.
• Heavy report calls can’t run concurrently.
• Term enrollments come from GET /academicterms/{id}/enrollments, paginated at 200 records/page.

Resolved issues, kept here since they’re the kind of thing that will recur:

• The Term Enrollments n8n node was aborting because its URL field was in Fixed mode, causing a SourceID expression to be sent as literal text instead of being evaluated. Fix: rebuilt in Expression mode and removed a 120-item page-guessing Code node that had been compensating for it. The workflow now runs green end-to-end.
• A related abort was initially suspected to be a Hyper-V/infrastructure problem, but traced to Populi rate-limiting from ~120 rapid HTTP requests firing at once. Fix was batching requests (~5 per batch, ~1000ms interval) with retry-on-fail, not an infrastructure change.

Access

Not yet documented: URL/hostname, who has admin access, whether login is via Populi’s own credentials or SSO through Google.

Dependencies

Systems that depend on Populi: Google Workspace provisioning, the nightly SQL Server sync (and by extension transcript generation), and Canvas access via the native integration.

Backup & recovery

Not yet documented — likely vendor-managed given Populi is third-party hosted, but not yet confirmed.

Notes

Referenced extensively across TCR’s IT policies (see Onboarding, Offboarding, PCI DSS, Data Governance & Security) as the central system most other account/data flows key off of.