An applicant portal on standard Education Cloud runs on Person Account, IndividualApplication, Application Timeline, Application Decision, and Action Plan records, shown through an Experience Cloud site. Applicants see a checklist and a decision, counselors work the application, and the registrar works contingencies as cases. ElevateActual built one this way for a health-sciences university that left TargetX.
Where the Institution Starts
The institution usually arrives with a vendor CRM in which an application is one record with a long list of fields: test scores, prior schools, essay status, decision, and deposit on the same row. The contract is ending, and the admissions dean wants a portal applicants will use on a phone. The worked example on this page is a private health-sciences university with graduate and doctoral programs across two campuses, which moved recruitment and admissions off TargetX onto standard Education Cloud and went live in summer 2026 ahead of its contract end. The full account is on our health-sciences university case study, and our admissions solution page describes the fixed-scope version.
Which Standard Objects Carry the Application?
Education Cloud (Agentforce Education) models an application across several standard objects rather than one. The split is the point: each object has its own sharing and automation.
- Person Account. The applicant. Salesforce Help notes that Education Cloud creates the Person Account when someone registers on the portal.
IndividualApplication. One record per application to a program for a term. APreliminaryApplicationRefrecord holds an application that is started but not submitted.LearningProgramandAcademicTerm. What the person applied to and when. AProgramTermApplnTimelinerecord joins a program, a term, and an Application Timeline so each program opens and closes on its own dates.ApplicationTimeline. The milestone dates: open, close, early release, and decision release. Salesforce Help states that Application Decision records are shared with portal users automatically on the release date set here.ApplicationDecision. The publicly released decision, separate from the internal review.ApplicationReviewholds reviewer scores and comments the applicant never sees.ActionPlan. The applicant's next steps. An Action Plan Template lists the application stages as tasks; assigning it to the program-term timeline gives every applicant the same checklist with their own completion state.DocumentChecklistItem. One per required upload: transcript, résumé, license, letter. The file attaches to the item, and the item's status drives the checklist.- Supporting person records.
PersonEducation,PersonExamination,PersonEmployment,PersonLanguage, andContactContactRelationfor prior schools, test scores, work history, languages, and family relationships. - Case. The institution's work on the application. Salesforce Help ships flow templates that create a case on submission and close it when the application is canceled or denied. We extend the same object to registrar evaluation and contingencies.
What Does the Applicant See?
The portal is an Experience Cloud site. Salesforce provides Application List and Application Details components with design attributes that control whether an applicant can edit tasks, submit, sign, cancel before submission, or withdraw after submission, and which header fields appear. Each option is off by default, and that default matters for the withdrawal question below.
Forms are a choice: Salesforce's native application stages run on OmniStudio components, a screen flow serves simpler inquiry forms, and the health-sciences university kept the FormAssembly forms it already owned, writing into the standard objects through its Salesforce connector. On the portal, the applicant sees the Action Plan as a checklist, each Document Checklist Item with an upload button, the application status, and, on the release date, the decision. The applicant does not see the review, the rubric, or the case.
Who Sees What at Each Step?
| Admissions step | Standard object | Applicant | Counselor | Registrar |
|---|---|---|---|---|
| Inquiry | Lead or Person Account | Confirmation only | Owner, full edit | No access |
| Start application | PreliminaryApplicationRef | Edit until submission | Read | No access |
| Submit | IndividualApplication, Case created | Read status and header | Owner of application and case | No access yet |
| Checklist and uploads | ActionPlan, DocumentChecklistItem | Complete tasks, upload files | Verify, mark received | No access |
| Review and score | ApplicationReview | Never | Read own reviews; committee edits | No access |
| Decision | ApplicationDecision | Read on release date | Create; release controlled by rules | Read |
| Registrar evaluation | Case (Evaluation record type) | Sees resulting tasks only | Read | Owner, full edit |
| Contingencies | Case (Contingency record type), one per item | Sees the task to clear it | Read | Owner, closes each |
| Enroll | AcademicTermEnrollment, LearnerProgram | Read | Read | Creates through Enroll Admitted Student or the SIS feed |
The applicant sees outcomes and tasks, never the work product, enforced by object permissions in the portal permission set and sharing on Case rather than by hiding fields.
How Are Decisions Controlled?
Three rules govern the decision screen, each enforced in Flow and sharing rather than in training.
- Ownership. Only the owner of the application, or a member of the program's queue, can create an
ApplicationDecision. A validation rule rejects anyone else. - Territory. Where a program runs on more than one campus, the campus on the application decides the decision queue and release calendar; a decision for the wrong campus fails validation.
- Registrar review. For doctoral and licensure programs, an Admit decision cannot be released until the registrar's evaluation case is closed. The timeline governs the day; the registrar's case governs whether the record is eligible on that day.
Because the public decision is its own object, these rules never touch the application or review records.
How Is Work Assigned?
New applications are assigned round-robin within the program's counselor group by a record-triggered flow on IndividualApplication. The flow reads an assignment table held in a custom metadata type, so admissions can edit it without a deployment, picks the next counselor, and sets the owner on the application and its case. Two guards keep it from failing quietly: if the program has no active counselors, the flow assigns a named default owner and posts a notification, and if a counselor is out of office, the flow skips them. A monthly report of applications owned by the default owner shows where the table is stale.
Why Can Applicants Not Withdraw Themselves?
Salesforce lets you turn on self-withdrawal in the Application Details component. We leave it off. A withdrawal has consequences in the SIS, in financial aid, and sometimes in a visa process, and an applicant who clicks Withdraw in frustration late at night should get a conversation, not a status change. On the portal, the applicant sees a Request to Withdraw action that creates a case for their counselor or advisor. The case has a short service-level target, the counselor calls and records the outcome, and the application status changes only when the case closes as Withdrawn.
How Do Registrar Evaluation and Contingencies Work?
At the health-sciences university, registrar evaluation and contingencies run inside Salesforce, with each contingency as its own case. Two Case record types carry it. An Evaluation case opens when the decision reaches a state the registrar must review and carries the registrar's checklist as an Action Plan. Contingency cases are created by the registrar, one per outstanding item such as a final transcript or a background check, and each produces a task the applicant sees in the portal. The admission is conditional until every contingency case is closed, and a roll-up on the application shows how many remain. Because each item is a case, the registrar's queue, reporting, and service-level targets come from standard Service Cloud features. Admitted students then move to the SIS through a staging-table integration, so nobody re-keys them; the SIS integration patterns page covers that handoff.
What Happens at Term Rollover?
Rollover done by hand turns a tidy build into a maintenance burden, so a scheduled flow handles it. Given a new AcademicTerm, the flow clones the prior term's ProgramTermApplnTimeline records for every active program, creates the new ApplicationTimeline records with dates shifted by the term offset, assigns the current Action Plan Template version, and opens the new term in the portal's New Application window on the open date. Admissions operations reviews the generated dates on one list view and edits exceptions. The flow never deletes the prior term's records, because in-flight applications still point to them.
The One Trap: Letting the Flat Record Model Leak Into the New Design
The package the institution is leaving stored the application as a flat record. The first instinct of every team is to recreate that: fifty custom fields on IndividualApplication for test scores, prior schools, and decision details. It works for a month and then costs you every feature you bought. Decision sharing on the release date only works if the decision is an ApplicationDecision. Document tracking in the portal only works if uploads are DocumentChecklistItem records. Transfer credit, the Student Recruitment agent (listed as beta on Salesforce Help), and the admissions analytics read the standard person records, not a custom field. The rule we hold to: a value goes on the application record only when it describes the application itself. Anything about the person goes on a person record, and anything about the institution's work goes on a case. Our standard objects first article explains why that trade is worth making.
What to Decide Before Building
- Program and term structure. Which programs open on which dates, and whether campus is a field or a separate program. This decides your
ProgramTermApplnTimelinerecords. - Forms tool. OmniStudio stages, screen flows, or a forms vendor the institution already owns.
- Who may decide, and who may release. Write the ownership, territory, and registrar-review rules down before the first flow is built.
- What a contingency is. Agree the list with the registrar, and whether any can be cleared by the SIS feed rather than by a person.
- Self-service boundaries. Which portal options for submit, cancel, and withdraw are on, and who answers the case when they are off.
- History. How many cycles migrate, and whether past decisions load as
ApplicationDecisionrecords or as a summary on the person.
If TargetX is the system you are leaving, the TargetX to Education Cloud page lists the object-by-object moves. The wider context is in our Salesforce for higher education guide.
Questions We Hear
Does Education Cloud include an applicant portal, or do we build one?
Both. Salesforce provides the Experience Cloud site template, the Application List and Application Details components, the New Application window, and the Action Center component for tasks. The institution configures the stages, the checklist, the branding, and the rules. Configuring those pieces is most of the work; custom code is rare.
Can applicants see their decision in the portal?
Yes. Salesforce Help states that Application Decision records are shared with portal users automatically on the decision release date or early release date set on the timeline. If the institution prefers to release by hand, the automatic sharing can be disabled in Setup and a flow or a counselor action shares the record instead.
How do recommenders and guardians fit in?
Salesforce Help notes that an IndividualApplication can relate to a contact who prepares an application on behalf of the applicant, and family or guardian relationships are ContactContactRelation records. Recommendation letters are Document Checklist Items with a request sent by flow to the recommender's email. Most of our clients do not issue recommenders portal logins and accept uploads through a signed link instead.
What does the counselor's day look like?
Counselors work from the application case, not from the application record. Their list views are cases by status and age, their tasks come from the Action Plan, and the application, person records, and documents sit as related lists on the case page. The health-sciences university replaced spreadsheet funnel tracking with CRM Analytics dashboards built on the same records, so the director and the counselor read the same data.
How long does an applicant portal take to build?
Our Recruitment and Admissions accelerator is live in about two months after structured discovery. A build with a forms vendor integration, registrar contingencies, and an SIS feed, like the health-sciences example, runs longer, mostly because of the integration and the historical data load rather than the portal itself. Plan backward from the vendor contract end.