Slate is a strong admissions CRM, and most institutions that run it for undergraduate admissions should keep doing so. Salesforce Education Cloud is the choice when the institution wants one platform across recruitment, continuing education commerce, student success, service, and advancement, or already runs Salesforce. ElevateActual builds the coexistence, not a rip and replace.
What Does Slate Do?
Slate, from Technolutions, is a CRM for admissions, student success, and advancement that is best known for undergraduate admissions. It covers inquiry capture, applications and reading, events and travel, communications, and reporting in one license. Technolutions publishes its license tiers by annual application volume, which is unusual in this market, and runs a Preferred Partner Program of implementation firms. Slate has a strong peer community, and institutions that do well on it tend to have a named in-house Slate owner.
This page is not a case for leaving Slate for admissions. It is about what happens when an institution's needs outgrow what one admissions-centered system is meant to hold: a continuing education unit that needs a storefront, an advancement office that wants donors on the same record as students, a service team that needs cases, or a campus that already runs Salesforce for something else. The Education Cloud admissions page describes what Salesforce offers for recruitment and applications, and the Salesforce for higher education guide explains how the clouds fit together.
Why Do Teams Consider Adding Salesforce?
The institution's situation is usually one of these.
- Continuing education needs to sell. A professional and continuing education unit needs a public catalog, a cart, discount codes, group registration, and enrollment records created at checkout. We build it as Commerce on Core: B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront, connected to Education Cloud so the enrollment record exists the moment the order does. Our Salesforce Commerce for higher education guide covers it.
- Advancement wants the whole relationship. Donors were applicants, students, and learners first. Salesforce Fundraising inside Education Cloud puts the gift on the same Person Account as the enrollment. Our advancement page describes that build.
- Student success and service need cases, care plans, and portals. Advising consoles, alerts, success teams, and a service desk for students are Education Cloud and Service Cloud capabilities.
- Salesforce is already there. The institution may run Salesforce for advancement, for the HR service center, or for a continuing education storefront. Adding a second platform for each new need is the thing to avoid.
- Graduate and professional admissions have a different shape. Rolling terms, interview stages, program-specific contingencies, and a registrar handoff into the SIS are easier to model as standard related records on Education Cloud. Some institutions move graduate admissions there and keep undergraduate admissions on Slate.
What Stays on Slate and What Runs on Salesforce?
The recommended patterns below are the ones we have built or scoped. The integration column is the cost.
| Scenario | Slate role | Salesforce role | Integration need |
|---|---|---|---|
| Undergraduate admissions on Slate; continuing education storefront on Salesforce | Inquiry to deposit for degree-seeking undergraduates | Commerce on Core storefront, Person Accounts for learners, CourseOffering and CourseOfferingParticipant enrollment, receipts | Light. A person match on email, name, and date of birth when a learner later applies, or none at all. The SIS is the bridge. |
| Undergraduate admissions on Slate; advancement on Salesforce | Admissions | Fundraising objects (GiftTransaction, GiftCommitment, GiftDesignation), alumni portal, giving storefront | Light to moderate. Alumni arrive from the SIS at graduation, not from Slate. Parent records may need a match. |
| Undergraduate admissions on Slate; graduate and professional admissions on Education Cloud | Undergraduate funnel | IndividualApplication, ApplicationTimeline, ApplicationDecision, Action Plans, Experience Cloud applicant portal for graduate programs | Moderate. Shared marketing suppression, a dedupe rule for people in both funnels, and one SIS feed for admits from each system. |
| Undergraduate admissions on Slate; student success and service on Salesforce | Admissions through matriculation | CarePlan, RecordAlert, ServiceAppointment, Case, student portal | Moderate. Admitted and enrolled students arrive from the SIS; Slate data that matters for advising (first-generation flag, intended major) comes through the SIS or a scheduled export. |
| One platform for the whole lifecycle | None after the institution's chosen transition date | Recruitment, admissions, commerce, student success, service, advancement on Education Cloud | Heaviest. A full admissions migration plus everything above. Only worth it when the institution has decided on one platform. |
The one trap in every coexistence pattern is the person match. A continuing education learner who buys a course at nineteen and applies to a degree program at twenty-one exists in both systems. If neither system owns identity, the institution ends up with two people and two sets of communications. Our recommended mapping makes the SIS the system of record for identity once a person has a student ID, and uses a documented match rule (email, name, date of birth, and student ID when present) on the Salesforce side before that. Slate keeps its own record of the applicant; Salesforce does not try to mirror it.
What Does the Salesforce Side Look Like?
On the commerce side, a learner is a Person Account. Each course is a CourseOffering under a LearningCourse and an AcademicTerm, priced through Pricebook2 and sold on the storefront. Checkout creates the Order Summary and a CourseOfferingParticipant record, so the registration exists without re-keying. The continuing education page shows what that storefront contains.
On the admissions side, where graduate programs move, an application is an IndividualApplication tied to a LearningProgram and an AcademicTerm, with ApplicationTimeline, ApplicationReview, and ApplicationDecision records and Action Plans as next steps. Applicants use an Experience Cloud portal. On the advancement side, gifts are GiftTransaction records against GiftDesignation funds on the same Person Account.
Automation is Flow and Platform Events: enrollment creation at checkout, waitlist promotion, acknowledgments, alert routing. Apex appears only where the platform requires it, such as a tax calculator extension. The SIS stays the system of record for the student; Slate stays the system of record for the undergraduate applicant; Salesforce holds the learner, the donor, and the service relationship.
How Do We Run the Project?
Coexistence is a build with a small migration inside it, so the sequence is lighter than a platform replacement, but the same disciplines apply.
- Discovery. Which populations Slate owns, which populations Salesforce will own, and where they overlap. We write the boundary down with the admissions office in the room, because a boundary nobody agreed to does not hold.
- Object mapping. For the Salesforce side, a mapping from the source (a legacy registration system, a spreadsheet, a prior CRM, or a Slate export for graduate applicants) to the standard objects above, plus the person match rule.
- Initial load and delta loads. Catalog, learners, and open enrollments or open applications load into a sandbox, then production, then deltas until cutover. Where graduate admissions moves off Slate, historical applications load as closed records.
- Parallel period. Short for commerce (a soft launch with staff orders), longer for graduate admissions (one to two weeks of side-by-side reading).
- Identity and username planning. If Slate's applicant portal and the new Salesforce portal both stay up, usernames must not collide and the applicant notice must say which portal to use for what. If learners already have a campus login, we decide whether the storefront uses it.
- Cutover. A dated switch for each scope. Commerce goes live before a registration window opens, not during it. Graduate admissions switches between cycles.
- Hot test. A real order through the storefront on launch day, with enrollment, receipt, and any SIS handoff confirmed; for admissions, a real test application read and decided on production.
Our other platform guides, including the same-platform moves from TargetX and Enrollment Rx, are on the migrations hub.
When Should You Not Add Salesforce?
- Admissions is the only need. An admissions office that is well served by Slate, values its predictable license, and has no commerce, advancement, or service requirement on the horizon does not need a second platform.
- Continuing education is small and transactional. A unit running a few dozen courses a year with a simple registration tool is not a Salesforce Commerce project yet.
- No administrator capacity. Salesforce needs an owner on staff, exactly as Slate does. Two platforms without two owners is a problem we will not help you create.
- The institution has decided on one platform and it is not Salesforce. Then this page is not your plan, and we would say so on the first call.
What to decide before building: which populations each system owns, the person match rule and who enforces it, whether graduate admissions moves now or later, and who owns the Salesforce side after go-live.
Questions We Hear
Do we have to leave Slate to use Salesforce?
No. The most common pattern we build keeps Slate for undergraduate admissions and runs continuing education commerce, advancement, or student success on Salesforce. The two systems meet through the SIS and a documented person match rule rather than a real-time integration. Leaving Slate is a separate decision that some institutions make for graduate programs first and others never make.
How do the two systems share data?
Mostly through the SIS. Once a person has a student ID, the SIS is the system of record for identity, and both Slate and Salesforce take their feed from it. Before that point, Salesforce applies a match rule on email, name, and date of birth to avoid duplicate Person Accounts. Direct Slate-to-Salesforce integration through scheduled exports is possible, but we recommend it only when a specific field is needed for advising.
Can graduate admissions move to Education Cloud while undergraduate stays on Slate?
Yes, and it is a pattern we have scoped and built. Graduate applications become IndividualApplication records with timelines, reviews, and decisions, served by an Experience Cloud applicant portal. Undergraduate admissions continues on Slate. The institution needs one marketing suppression list across both funnels and a dedupe rule for the small number of people who apply to both.
Is Salesforce more expensive than Slate?
They are priced differently, and we do not quote either. Slate publishes license tiers by application volume. Salesforce publishes a list price per user for Education Cloud, with Commerce, Experience Cloud, and Agentforce as separate line items. The comparison depends on how many clouds the institution would use; a storefront plus advancement plus service on one platform compares differently from admissions alone.
What does the continuing education storefront look like?
A public catalog with categories, search, a cart, discount codes, group registration, and guest or logged-in checkout, built on an LWR Experience Cloud site. Checkout creates the order and the CourseOfferingParticipant enrollment record. Our house demonstration storefront, ElevateActual University, shows the pattern with fifty programs across seven categories and a single cart.
How long does the Salesforce side take?
Our fixed-scope Commerce accelerator goes live in about two months after structured discovery. Advancement migrations from a legacy system run longer because of gift history reconciliation. Moving graduate admissions off Slate is sized like any admissions migration, typically a few months between cycles. Each scope has its own cutover date, so the institution is never waiting on everything at once.