Student success on Education Cloud is a set of standard objects: an advising Case per learner, Care Plans and Action Plans for interventions, Record Alerts for signals, Success Teams for who is responsible, plus watchlists, pulse checks, and Einstein Advising Summary. The SIS stays the system of record. ElevateActual designs the signals, the priority logic, and the ownership first.
Where the Institution Starts
The advising office usually has three systems that do not talk: the SIS, which knows registration, grades, and holds; an early-alert tool or a shared inbox, where faculty raise concerns; and spreadsheets, where advisors track who they have called. A student who stops registering shows up in the SIS report two weeks after the deadline, in the advisor's spreadsheet a week later, and in nobody's queue. The director cannot say how many students have an open intervention or who owns it. That is the situation our student success solution is built for; this page explains the standard pieces and the design decisions.
What Does Education Cloud Provide for Student Success?
Salesforce's Student Success documentation describes the set as of October 2026.
- Advising Case. Each learner has an advising case per support context. Salesforce Help models advising workspaces (academic advising, career advising, wellbeing) as Case record types, so the case is where everything else attaches.
- Advisor console and director console. The advisor console ships with the Student Success app and is where advisors create care plans and alerts. The director console is where a director creates programs and benefits, assigns advisors, and watches institutional indicators.
- Care Plans. A
CarePlanis the intervention: goals and benefits assembled from a Care Plan Template. Salesforce Help notes that a care plan can be applied to up to twenty alerts at a time. - Action Plans. The task list inside a care plan or on its own. Learners see their action plans and tasks through the Action Center component on the portal.
- Record Alerts. A
RecordAlertrelates to the learner's case and carries a category and severity. Alerts are created on the console or by flows, and their status can be changed in bulk. - Success Teams. Case team roles, members, and predefined case teams define who can see a learner's advising case. A
SuccessTeamrecord marks a case record type as an advising workspace and can attach a support pool for scheduling. - Watchlists. A
WatchlistedLearnerrecord flags a learner for closer monitoring, created from the case page or in bulk from the Academic Term Enrollments list view, with an escalation option and an end date. - Pulse checks. A
PulseCheckis a short feedback form sent from a template and recorded against the learner at a date and time. - Einstein Advising Summary. A generated summary of the advising case so an advisor can prepare for an appointment quickly.
- Intelligent Degree Planning. A planner on the portal built from
LearnerPathwayand the learning program plan, with an optional approval step for advisor review.
Who Is the System of Record?
The SIS, always. Banner, Colleague, Jenzabar, or PeopleSoft owns registration, grades, holds, and the academic record. Salesforce holds the relationship and the interventions: who talked to the student, what was promised, what the student committed to, and whether it happened. The feed from the SIS is one-directional for academic data and populates AcademicTermEnrollment, CourseOfferingParticipant, results, and holds. Salesforce never writes a grade. Anything that flows back, such as a hold release request the registrar has agreed to, goes through a supported API and never a direct database write. Our SIS integration patterns page covers the feed design.
Which Signal Triggers Which Action?
The design question is not which features to turn on but which signals the institution trusts, which object carries each one, who gets told, and what they do next. The table is the mapping we start from and tune with the advising director.
| Signal | Object that carries it | Who is alerted | Action |
|---|---|---|---|
| Missed registration for next term | No AcademicTermEnrollment for the upcoming term after the priority deadline, found by a scheduled flow | Assigned advisor; director if a program's count crosses a threshold | RecordAlert created; advisor task to contact within five business days; care plan if no response |
| Registration hold | Hold from the SIS feed, modeled with Education Cloud holds and blocks | Advisor and the office that owns the hold | Alert with the hold type; task to the owning office; learner sees the resolution steps on the portal |
| Low pulse check | PulseCheck below the institution's threshold | Advisor; wellbeing team for wellbeing items | Alert with wellbeing category; same-day outreach task; optional care plan from the wellbeing template |
| Faculty concern | RecordAlert raised by faculty through a screen flow | Advisor; tutoring center if academic | Alert triaged by the advisor; benefit assigned from the tutoring program |
| Midterm grade below threshold | CourseOfferingParticipantResult from the SIS feed | Advisor | Alert per course; care plan applied in bulk to all alerts for the learner |
| Stop-out pattern | Two consecutive terms without enrollment while the LearnerProgram is active | Advisor and the re-enrollment team | Watchlist entry with escalation; re-enrollment care plan; outreach sequence |
| Advisor judgment | WatchlistedLearner created by the advisor | The advisor who created it | Closer monitoring; end date set when the concern is resolved |
How Should the Priority Indicator Work?
Salesforce provides the raw material for a priority indicator (alert severity, watchlist escalation, pulse scores, enrollment status) but not the formula, and the formula differs by institution. We build it in Flow. A scheduled flow scores each open advising case from the signals in the table, weighted by values held in a custom metadata type, and writes the result to a field on the case. An administrator edits the weights in Setup with no deployment, so when the director decides a hold matters more than a low midterm grade this year, that is a five-minute change. The console's list views sort on the indicator, so changing the weights changes the day's call list.
How Do You Assign Care Plans at Scale?
Assigning care plans one at a time from the console works for a caseload of sixty, not for a first-year cohort of nine hundred. We add a screen flow on the Academic Term Enrollments list view: the director selects a filtered set of learners, picks a Care Plan Template and the advisor or support pool, and creates the care plans and their action plans in one run. The flow writes a summary record showing when the cohort was assigned and which template version was used. Salesforce's own bulk watchlist action follows the same list-view pattern, so advisors find it familiar.
Why Keep the Snapshot Component Standard?
Salesforce ships the Learner Profile, Learner Progress, and Learner Progress Summary components, which aggregate academic data onto one view for advisors and learners. The temptation is to rebuild it as a custom component. We keep the standard component on the page as it ships, read-only, and put the institution's extras in a separate section next to it. The standard component then inherits every Salesforce release update, and no one re-tests a custom snapshot three times a year. Its data comes from the SIS feed, so the advisor sees the SIS picture, delayed by at most one feed cycle.
How Do You Track Stop-Outs and Registration?
The SIS reports who registered, not who did not, because there is no record to report. In Education Cloud, the LearnerProgram record says the learner is active, and the AcademicTermEnrollment records say which terms they enrolled in. A scheduled flow compares the two after each registration deadline and creates the alert for the gap; the same comparison across two or three terms produces the stop-out list. Re-enrollment is a care plan with an outreach sequence, and the outcome is recorded on the LearnerProgram status so the next term's comparison does not raise the same alert again.
What to Decide Before Building
- Who owns a care plan. The assigned advisor, the support pool, or the program director. Ownership decides accountability for overdue tasks and the sharing model.
- What a case is in advising. One case per learner for their whole time, one per term, or one per concern. We recommend one long-running case per workspace per learner; alerts and care plans are what open and close.
- What the SIS feed includes. Enrollments and holds at minimum. Midterm grades and attendance make the alert table useful, and each has a data-sharing conversation attached.
- The signal list and thresholds. Agree the table above with the advising director and the registrar, including the pulse threshold and the days after a deadline before a missed registration becomes an alert.
- Who may see wellbeing data. A wellbeing workspace needs its own case record type and success team roles so academic advisors do not see counseling notes.
- Einstein features. Whether Einstein Advising Summary is on at launch or after advisors trust the data, and who reviews summaries in the first term.
Institutions coming from Student Success Hub will recognize most of these objects; the Admissions Connect and Student Success Hub migration page maps the old success plans and alerts to the new records. The fixed-scope version is the Student Success accelerator on our accelerators page; the wider context is in the Salesforce for higher education guide.
Questions We Hear
Does Salesforce replace our early-alert tool?
It can carry the same function. A faculty concern becomes a RecordAlert raised through a screen flow on the portal or from a link in the LMS, it lands on the learner's advising case, and the advisor triages it on the console. Whether to retire the separate tool is a contract decision; the technical case for consolidating is that the alert then sits next to the care plan, appointments, and enrollment data.
Can students see their own care plan?
Yes, through the Action Center component on the Experience Cloud portal, which shows the learner their care plans, action plans, and tasks. What they see is governed by sharing sets on the portal, so a learner sees only their own records. Internal notes on the case and alerts raised by faculty are not shown to the learner unless the institution decides to expose them.
How do success teams handle advisor turnover?
Predefined case teams are the answer in Salesforce Help's model. Staff and their roles are grouped into a reusable team, and that team is assigned to the advising workspace or attached as a support pool. When a person leaves, the predefined team is updated once and every case that uses it reflects the change. Named advisors are still individual case team members, reassigned from a list view.
What does Einstein Advising Summary produce?
A generated summary of the learner's advising case, drawn from the records on that case, intended to help an advisor prepare for an appointment or make a decision at short notice. It requires Einstein generative AI to be enabled for the org and the Einstein Summary component on the case page. It summarizes what is in Salesforce, so the quality of the summary follows the quality of the feed.
How long does a student success build take?
Our Student Success accelerator (student 360, alerts, and success plans) is live in about two months after structured discovery, with the SIS feed for enrollments and holds included. Midterm grades, attendance, pulse checks, and a wellbeing workspace with separate sharing extend the work, mostly in data agreements and testing rather than configuration. The advising director's availability for the signal and threshold decisions is usually the pacing item.