- Institution
- A private health-sciences university with graduate and doctoral programs, two campuses
- Replaced
- TargetX managed package
- Built on
- Standard Education Cloud, Experience Cloud applicant portal, CRM Analytics
- SIS
- Jenzabar, through staging tables and scheduled ETL
- Live
- Summer 2026, ahead of the TargetX contract end
- Named?
- No. The university has not spoken publicly, so we describe it without naming it.
A private health-sciences university with graduate and doctoral programs on two campuses ran recruitment and admissions on the TargetX managed package, with registrar evaluation outside the CRM and admitted students re-keyed by hand into its Jenzabar SIS. ElevateActual moved admissions onto standard Education Cloud, with an applicant portal, registrar evaluation inside Salesforce, funnel dashboards, and a scheduled SIS handoff, live in summer 2026 before the TargetX contract ended.
The Situation
The university enrolls graduate and doctoral students across several colleges and two campuses, with intake from a centralized application service as well as its own forms. TargetX had served admissions for years, but its flat record model meant that programs, terms, and campuses were attributes on a person rather than records in their own right. Registrar evaluation happened outside the CRM. Once a student was admitted, staff re-keyed the record into Jenzabar. Funnel reporting lived in a spreadsheet.
The deadline was fixed. Access to TargetX ended on a contract date in summer 2026, which meant the new system had to be live, with history migrated, before that date.
What We Built
| Admissions step | Standard Education Cloud object or feature | Who works there |
|---|---|---|
| Inquiry | Person Account, inquiry form with campaign attribution | Marketing, admissions counselors |
| Program and term | LearningProgram, AcademicTerm | Admissions operations |
| Application | IndividualApplication with Application Timelines, application form, and checklist tasks | Applicant, counselor |
| Next steps for the applicant | ActionPlan templates assigned by program | Applicant, through the portal |
| Registrar evaluation | Cases, one per contingency, linked to the application | Registrar |
| Decision | Application Decision, with a decision screen that enforces ownership, territory, and registrar review | Admissions leadership |
| Admitted student to SIS | Staging tables and scheduled ETL to Jenzabar in both directions | IT, with no re-keying |
| Reporting | CRM Analytics funnel and aging dashboards | Deans, admissions leadership |
| Outreach | Dialer and SMS on the Case, email through Marketing Cloud with consent captured in Data 360 | Counselors |
The Design Decisions That Mattered
- Standard objects, not a rebuilt TargetX. The temptation on a same-platform migration is to recreate the package's custom objects. We used the Education Cloud admissions model as designed and mapped history into it. The applicant portal article describes the resulting shape.
- Each contingency is its own case. A missing transcript and a pending prerequisite are different work for different people. Cases give the registrar a queue and give the applicant a status.
- Round-robin with a fallback owner. New applications route to counselors by program and campus, with a default owner so nothing sits unassigned when someone is out.
- Applicants cannot self-withdraw. A withdrawal request becomes a case to an advisor, which preserved a conversation the university valued.
- A new campus is configuration. When a further campus joined during the project, it was added through records, not a new process.
What Went Sideways
The SIS integration was the long pole. The SIS vendor was slow to engage and at one point recommended renewing the legacy CRM instead; the integration platform had its own open tickets. Production deployment waited on that work until a few weeks before go-live, which compressed training into the final days. The handoff went live on staging tables with scheduled jobs in both directions, which we recommend as the resilient pattern when a vendor's real-time option is uncertain (see SIS integration patterns).
Two smaller items are worth naming because they recur. Because the legacy org stayed up until the contract date, Salesforce's requirement that usernames be unique across orgs forced temporary usernames in the new org, a wrinkle we now plan for on every same-platform migration. And several hundred test records created during UAT cluttered registrar views after go-live until they were tagged and purged, which is now a line on our migration checklist.
What Is Next
A backlog of refinements gathered during the first admitted-student cycle, onboarding of the additional campus, and a planned pilot of Agentforce for routine inquiry and scheduling questions. Student success and a continuing education storefront are candidates for later phases on the same org.
Questions We Hear
Why is this university not named?
It has not spoken publicly about the project, and we name a client only when the client has. The facts above are limited to what the project delivered; we publish no metrics for it.
Is leaving TargetX a migration or a new implementation?
Both at once. The data already lives in Salesforce, which simplifies the move, but the admissions process is rebuilt on standard Education Cloud objects rather than package objects. Our TargetX to Education Cloud guide covers the pattern.
How long did it take?
About ten months from the implementation statement of work to go-live, with the SIS integration setting the pace. The admissions configuration itself was ready months earlier.
Did the registrar move into Salesforce?
For evaluation, yes. Contingencies, holds, and review decisions are worked in Salesforce as cases linked to the application. The official student record is still created in the SIS, automatically, once the student is admitted.
What would you do differently?
Start the SIS vendor conversation on day one, with the institution's contract owner in the room, and agree on the staging-table fallback before anyone promises a real-time integration.