Salesforce Higher Education Glossary

Salesforce names its higher education products inconsistently, and the people writing RFPs pay for it. This glossary defines the terms that appear in an Education Cloud or Salesforce Commerce build at a university, says what each one is not, and points to the ElevateActual page that goes deepest on it. Entries are grouped by where the term comes from.

Education Cloud and Its Predecessors

If the article is on Salesforce Help, the product is called Education Cloud; if the page is on salesforce.com, the same product is called Agentforce Education or Agentforce 360 for Education. The guide to Salesforce for higher education walks through the clouds and modules in order.

EDA (Education Data Architecture)

EDA is the free managed package Salesforce.org published so that universities on Sales Cloud or Service Cloud shared one account, contact, affiliation, and program enrollment model. It is not Education Cloud and does not share its data model: EDA's hed__Program_Enrollment__c and hed__Course_Enrollment__c are custom objects, while Education Cloud uses standard ones. As of October 2026 Salesforce has not announced a retirement of EDA. In a build, EDA is usually the system being left. See moving from EDA to Education Cloud without a data freeze.

HEDA (Higher Education Data Architecture)

HEDA is the original name of EDA. Salesforce.org dropped the "Higher" when the package was extended to K-12, but the namespace prefix stayed hed__, which is why a ten-year-old field still announces the old name. HEDA is not a separate product; anyone who says "we run HEDA" runs EDA, possibly an old version. In a build, the name appears only in legacy field API names, old documentation, and procurement records. The EDA migration article applies unchanged.

Education Cloud

Education Cloud (Agentforce Education) is Salesforce's paid industry product for higher education. It adds standard objects for learning, applications, academic terms, success plans, advancement, and student financials, and it uses Person Accounts for learners. It is not EDA, a free package with a custom-object model, and it is not a student information system. In a build it is the system of engagement, with the SIS remaining the system of record. The Salesforce for higher education guide maps its modules to campus functions.

Admissions Connect

Admissions Connect is a Salesforce.org managed package, built on EDA, that gave admissions offices application review, applicant checklists, and an applicant portal. It is not part of Education Cloud, whose Recruitment and Admissions module does the same work on standard objects: IndividualApplication, Application Timelines, and Action Plans. As of October 2026 Salesforce has not announced a retirement, but the Data Migration Kit maps Admissions Connect data to Education Cloud. In a build it is a migration source. See Admissions Connect and Student Success Hub to Education Cloud.

Student Success Hub

Student Success Hub is a Salesforce.org managed package, also built on EDA, for advising: appointments, success plans, alerts, and case management. It is not the Student Success module in Education Cloud, which covers the same ground with care plans, alerts, and advisor consoles on standard objects. As of October 2026 no retirement has been announced, and the Data Migration Kit includes a package specifically for Student Success Hub data. In a build it is the source for care plan and appointment migration. The migration page lists what carries over.

Advisor Link

Salesforce Advisor Link, usually shortened to SAL, was the Salesforce.org advising package that preceded Student Success Hub. An org that bought SAL years ago most likely runs Student Success Hub today. It is not an Education Cloud feature and not a current product name. In a build, it shows up in old contracts, permission set labels, and RFPs written from an earlier template; read "Advisor Link parity" as Student Success Hub parity and map it to Education Cloud care plans. Context is in the student success article.

Data Migration Kit

The Data Migration Kit is Salesforce's set of unmanaged packages and Data Processing Engine definitions for moving data from EDA, Admissions Connect, and Student Success Hub into Education Cloud. It moves data in clusters and converts account and contact records to Person Accounts. It is not a metadata migration: it does not move custom code, Flows, reports, page layouts, or integrations. Salesforce documents it at Migrate Your Data to Education Cloud; the data migration checklist covers everything around it.

Person Account

A Person Account is a Salesforce Account record that also carries a Contact, so one individual can be the customer, the applicant, and the learner without a parent organization. Education Cloud and D2C Commerce both expect Person Accounts for individuals. It is not the EDA Administrative Account model, where each Contact hung under a one-person Account, and converting between the two is the hardest part of an EDA migration. In a build, every learner and shopper is a Person Account. The standard objects first article explains why we model learners no other way.

The Learning Data Model

Education Cloud models a degree, a certificate, and a one-evening noncredit workshop with the same objects. The continuing education data model article walks one course from catalog to enrollment through these records.

Learning

The Learning object, available in API version 57.0 and later, defines a training that can be offered as a course, a program, or an on-site experience. It is the abstract definition that Learning Program and Learning Course records point to, which is why it confuses people: nobody enrolls in a Learning. It is not the section a learner buys. In a build, Learning records are created once per credential or course definition and rarely touched again. See the data model article.

Learning Program

LearningProgram represents one or more trainings grouped into a program that leads to a credential: a degree, a certificate, or a badge series. It is not a Learning Course, which is a single course definition. Education Cloud uses the same object for degree and continuing education programs; the duration unit accepts credit hours or Continuing Education Units. In a build, Learning Programs hold the application target for admissions and the bundle definition for a certificate sold on a storefront. See the continuing education data model.

Learning Course

LearningCourse is the catalog definition of a course within a learning framework: title, description, credit or CEU value, prerequisites. It is not the scheduled instance; that is the Course Offering. One Learning Course has many Course Offerings across terms and modalities. Teams coming from registration platforms often collapse the two into one record, then discover they cannot report on a course across years. In a build, Learning Course is what marketing copy describes, while the storefront sells the offerings underneath it. Details are in the data model article.

Course Offering

CourseOffering is an instance of a Learning Course with dates, location, delivery format, capacity, and instructor: a section, in registrar language. It is not the course itself and not the enrollment. On a Commerce on Core storefront, the Course Offering is the record that becomes a purchasable product, and automation keeps product availability in step with offering capacity. Salesforce describes learner registration against offerings in Set Up Course Registration. See how offerings become products.

Course Offering Participant

CourseOfferingParticipant records a learner's enrollment in a specific Course Offering. It is the registration. It is not an Academic Term Enrollment, which records standing in a term rather than a seat in a section. In a build this is the record checkout creates: order placed, Order Item Summary read, participant written, SIS notified. Waitlists are the same object with a different status, which is how DU Learning Exchange handles them without a custom object. The continuing education data model article covers the status values.

Academic Term

AcademicTerm defines an academic period, and terms can nest: a semester containing two sessions, or a year containing quarters. It is not a date field on a course offering; it is its own record, which lets reporting and registration windows key off it. Continuing education units that say they have no terms do; the term is the catalog season. In a build, Academic Terms drive the storefront's category structure and the open and close dates for registration. The data model article shows how terms shape the catalog.

Academic Term Enrollment

AcademicTermEnrollment records a learner's enrollment in an Academic Term: the fact of being an active student that term, with program and status attached. It is not a Course Offering Participant, which is per section. Degree programs need both; most noncredit programs need only participants and can skip term enrollment entirely. In a build, Academic Term Enrollment is what student success tooling and holds evaluate, and what an SIS integration often supplies. The student success article shows how advisors use it.

Learner Pathway

LearnerPathway, available in API version 61.0 and later, represents a learner's planned path to completion of enrolled Learning Programs: which courses in which terms. It is the object underneath Intelligent Degree Planning. It is not the enrollment itself, and not a Care Plan, which addresses a problem rather than a plan of study. In a continuing education build it is usually out of scope; in a degree-completion or student success build it is central. Salesforce describes the planning features on its student success Help page. See the student success article.

Individual Application

IndividualApplication is the standard application record. Salesforce defines it as the preferences of an applicant during program enrollment, which undersells it: with record types per program term it is the full admissions application. It is not an EDA or Admissions Connect application object, and not a Lead. In a build, each form submission creates one Individual Application linked to a Person Account and a Learning Program, with Application Timelines and Action Plans hanging off it. The applicant portal article shows the chain on standard objects.

Application Timeline

ApplicationTimeline holds the milestone dates of an application: submitted, complete, under review, decision released, deposit received. It is not the stage picklist on the application; the timeline keeps history where a picklist keeps only the current value. In a build, timelines feed the applicant portal's progress view and the funnel dashboards an admissions dean wants, replacing the spreadsheet that held "date complete" by hand. See building an applicant portal on standard Education Cloud.

Action Plan

An Action Plan is a templated set of tasks attached to a record. Education Cloud uses Action Plan templates to represent an application's required items, each stage becoming a task, and again in the Student Success Action Center as a learner's to-do list. It is not a Care Plan, which carries goals and benefits rather than tasks. Salesforce documents the admissions use in Create an Action Plan Template for Applications. See the applicant portal article.

Care Plan

A Care Plan is the Student Success record that addresses a learner's situation with goals, benefits, and the people responsible. Advisors create one from a template or apply one to a record alert. It is not an Action Plan, which is a task list, and not a Student Success Hub success plan. In a build, Care Plans are what the advisor console shows and what the Action Center surfaces to the learner. Salesforce's overview is Support Learners with Care Plans; see also the student success article.

Holds and Blocks

Holds and Blocks is the Education Cloud framework that lets a registrar define a policy, place a hold on learners who fail it, and block them from registration until it is resolved. It needs the Education Cloud Advanced Academic Operations for Experience Cloud add-on. It is not a validation rule and not a storefront buyer-group restriction. In a build, holds are evaluated by Business Rules Engine expression sets and invocable actions. Salesforce documents it at Holds and Blocks; see also Flow-first automation for enrollment.

Student Financials

Student Financials is the Education Cloud module that models fees as Products, shows learners an account view on the learner portal, and takes payment through a Salesforce Payments merchant account. It is not a storefront: no cart, no catalog browsing, no guest checkout, because it bills a known learner for known charges. In a build, Student Financials suits tuition deposits and term fees, while a Commerce on Core storefront suits open enrollment. Salesforce documents it at Student Financials. See how universities take payments.

Commerce Terms

Salesforce sells three things under the word Commerce, and only two of them run on the Salesforce Platform. The Salesforce Commerce for higher education guide compares them in one table.

Commerce on Core

Commerce on Core is ElevateActual's term for B2B or D2C Commerce built on the Salesforce Platform: an LWR Experience Cloud storefront, Order Summary and Order Item Summary records, Person Accounts for learners, and a connection to Education Cloud so that checkout creates Course Offering Participant records. It is not B2C Commerce, the separate stack. Salesforce has no official definition of the phrase, so define it in any contract. There is no Salesforce product with "Education" in its commerce name. The Salesforce Commerce guide sets out the reference architecture.

D2C Commerce

D2C Commerce is Salesforce's direct-to-consumer store on the Salesforce Platform, built in Experience Builder on LWR, with shoppers as Person Accounts and guest checkout available. It is not B2C Commerce, despite the near-identical name, and not a B2B store, although the two share most objects and administration. In a build, D2C Commerce is the usual choice for an open-enrollment continuing education storefront where most buyers are individuals. The commerce guide explains when B2B's account model is worth the extra setup.

B2B Commerce

B2B Commerce is the account-based store on the Salesforce Platform: buyers belong to Accounts, Buyer Groups control which Accounts see which stores and price books, and contacts order on behalf of their organization. It is not B2C Commerce, and not the old CloudCraze package it descends from. In a higher education build, B2B Commerce appears when corporate partners register cohorts, when an employer pays for its staff's certificates, or when departments buy on internal budgets. The commerce guide covers corporate cohort registration.

B2C Commerce

B2C Commerce is the former Demandware platform: a separate, multi-tenant retail stack with its own hosting, code base, and release cycle, connected to Salesforce CRM through integration rather than shared objects. It is not D2C Commerce, and buying it to sell courses means building the Education Cloud connection you would otherwise get for free. ElevateActual does not use it for higher education. In an RFP, "Commerce Cloud B2C" is the name to question. See the comparison in the Salesforce Commerce guide.

Storefront Next

Storefront Next is Salesforce's React-based storefront template for B2C Commerce. It is not an option for a D2C or B2B store on the Salesforce Platform, whose storefronts are LWR Experience Cloud sites. Salesforce's accessibility conformance report index lists Storefront Next separately from Experience Cloud LWR for that reason. In a higher education build on Commerce on Core, Storefront Next does not appear. The Salesforce Commerce guide keeps the three product names straight.

LWR (Lightning Web Runtime)

LWR, Lightning Web Runtime, is the rendering framework for modern Experience Cloud sites, including every B2B and D2C storefront template. Pages are assembled from Lightning Web Components, and load faster than the older Aura templates. It is not Aura, and a site cannot be switched between the two; it is rebuilt. In a build, LWR is where the storefront, the applicant portal, and the learner portal live. The WCAG checklist for a university storefront on LWR covers the builder's share.

Order Summary

OrderSummary is the record Salesforce Commerce creates when a shopper completes checkout: the durable, customer-facing view of an order. It is not the Order record, which exists beneath it, and not the cart, which is discarded at checkout. In a Commerce on Core build, post-purchase automation keys off the Order Summary, and the receipt, the enrollment, and the SIS message all trace back to it. The article on selling courses through Salesforce Commerce follows a purchase from cart to Order Summary.

Order Item Summary

OrderItemSummary is one line of an Order Summary: one product, quantity, price, tax, and status. It is not the Product record and not the Course Offering; it references the product that references the offering. In a build, enrollment automation reads each Order Item Summary, finds the Course Offering behind it, and creates one Course Offering Participant per seat. Refunds and cancellations are recorded at this level, which is why refund policy decisions belong before build. The tax, refunds, and receipts article shows what happens to a line when a learner withdraws.

Buyer Group

BuyerGroup is the Salesforce Commerce construct that connects a set of Accounts to a store, an entitlement policy, and one or more price books. Membership decides what a shopper can see and what they pay. It is not a Salesforce public group or a permission set, and not a promotion. In a higher education build, Buyer Groups are how a corporate partner's employees see a negotiated price, how alumni see a discount, and how a hidden catalog stays hidden. The Salesforce Commerce guide covers group pricing.

Pricebook

A Pricebook, object name Pricebook2, is a named list of prices, one PricebookEntry per product. A store has a standard price book plus strategy price books attached through Buyer Groups. It is not a promotion, and not the price field on the Course Offering, which Education Cloud does not use for selling. In a build, in-state, member, and corporate rates each become a price book, and every sellable product needs an entry in the standard book or it will not display. See what drives the cost of a storefront.

Product Variation

A Product Variation is Salesforce Commerce's way of selling one parent product in several versions, with an attribute set (term, modality, session) distinguishing each variant. It is not the same as listing each section as a separate product, which is simpler and often right when sections differ in dates only. In a build, variations suit a course offered every term in online and in-person formats; separate products suit one-off workshops. The selling courses article explains how sections, terms, and modalities map to products.

Salesforce Payments

Salesforce Payments is Salesforce's own payment product for Commerce on Core and Student Financials, with a merchant account provisioned through Stripe and the payment form presented inside the Salesforce checkout. It is not a replacement for the campus payment processor, and not required: a storefront can instead hand off to a hosted checkout at TouchNet or Transact CashNet. In a build, Salesforce Payments is the fastest path when the institution will add a merchant account; hosted checkout wins when the bursar insists on one processor. The payments article compares them.

Hosted Checkout

Hosted checkout is the pattern where the storefront builds the cart and the order, then redirects the learner to a payment page the processor hosts, such as Transact CashNet eMarket or TouchNet uPay. Card data never touches Salesforce. It is not an embedded payment form. In a build, the handoff is signed, the item code equals the course number so finance can reconcile, and a post-authorization adapter writes the result back to the order. See how universities take payments.

Payment Gateway Adapter

A payment gateway adapter is the Apex class that tells Salesforce Commerce how to talk to a particular processor, implementing the commercepayments interfaces for authorization, capture, refund, and the return trip from a hosted page. Salesforce ships adapters for its own payments product; a CashNet or TouchNet integration needs a custom one. It cannot be a Flow, which makes it one of the few places where the standard-first rule permits Apex. The payments article describes the post-authorization adapter we use with CashNet.

Tax Calculator Extension

A tax calculator extension is a Salesforce Commerce extension point, implemented in Apex, that computes tax per cart line during checkout. Salesforce provides a basic standard tax integration and a hook for third-party tax services; an institution that charges tax on some products and not others usually needs the extension. It is not a Flow. Most universities are exempt as sellers of instruction but not as sellers of books or merchandise, so the extension decides line by line. The tax, refunds, and receipts article covers the decisions behind it.

Agentforce Terms

Agentforce is Salesforce's agent platform, and in education it arrives as both a product rename and an add-on. The Agentforce for higher education guide lists the agents Salesforce Help documents.

Agentforce Education

Agentforce Education is the name Salesforce has used for Education Cloud on its product pages since Dreamforce 2025. It is the same product, license, and objects; the Help tree and release notes still say Education Cloud. It is not Agentforce for Education, which is the separately licensed agent add-on that requires Education Cloud underneath it. The one-word difference is the whole distinction, so quote the exact name on any order form. The Agentforce guide sorts the names out.

Agentforce 360 for Education

Agentforce 360 for Education is a third name for the same product, used on the salesforce.com education landing page after Salesforce rebranded its platform as Agentforce 360. It is not a new edition and not a bundle with different contents. In a build, you will see this name in sales decks, Education Cloud in Help articles, and Agentforce Education on product pages, all in the same week. Pick one for your internal documents. The Agentforce for higher education guide explains what the add-on adds.

Agentforce Subagent

A subagent is a scoped unit inside an Agentforce agent: a set of instructions, the actions it may call, and the situations that route to it. Salesforce previously called these topics and renamed them subagents; some Help URLs still carry "topics" while the article titles say "subagents." It is not a separate agent and not a Flow, although its actions are often Flows. Salesforce's education product page lists eight prebuilt subagents, including Course Search Support and Student Financials. The subagents for continuing education article maps each one to a storefront use.

Platform and Partner Terms

The platform pieces an Education Cloud project touches, and the partner vocabulary in proposals. The how we deliver page describes how ElevateActual uses them.

Experience Cloud

Experience Cloud is Salesforce's product for websites and portals that face people outside the org. A site runs on an LWR or Aura template, authenticates through Salesforce identity, and shows CRM data according to sharing rules. It is not the storefront by itself; a Commerce on Core storefront is an Experience Cloud site with Commerce installed in it. In a build, Experience Cloud hosts the applicant portal, the learner portal, and the storefront. The applicant portal article is the worked example.

Experience Cloud for Education

Experience Cloud for Education is the license SKU for learner and alumni communities on Education Cloud, priced per login or per member on Salesforce's published list. It is not a different technology; sites built with it are ordinary Experience Cloud sites. The distinction is contractual: which external users count, and how. It is also not the Commerce license, which is priced separately. Salesforce publishes the terms on its Experience Cloud for Education pricing page. See the higher education guide on licensing.

Data 360 (Data Cloud)

Data 360 is the current name for Salesforce Data Cloud, the data platform that ingests records from the SIS, LMS, and other sources, resolves identities across them, and makes the unified profile available to Education Cloud, Agentforce, and analytics. It is not a reporting tool and not required for Education Cloud. In a build it appears when the institution wants agents or segments grounded in data that lives outside Salesforce, and it is licensed separately. Salesforce documents the education setup at Data 360 for Education. See the higher education guide.

MuleSoft

MuleSoft is Salesforce's integration platform: Anypoint for API-led integration, plus lighter tools for Flow-based integration. It is not required to connect Education Cloud to Banner, Colleague, Jenzabar, or PeopleSoft; supported SIS APIs, staging tables, or another middleware product do the same job. In a build, the question is who maintains the integration after go-live; MuleSoft answers that well if the campus has MuleSoft skills and badly if it does not. The SIS integration patterns article compares the options by SIS.

Flow

Flow is Salesforce's declarative automation tool: record-triggered, scheduled, screen, and autolaunched flows. It is not Apex, and not Workflow Rules or Process Builder, the older tools Salesforce has replaced with Flow. ElevateActual's rule is that record automation lives in Flow and Platform Events, with Apex only where the platform requires it. In a build, Flow creates the Course Offering Participant after checkout, sends the receipt, and notifies the SIS. The Flow-first automation article shows the pattern and its limits.

Platform Event

A Platform Event is a publish-and-subscribe message on the Salesforce Platform. A flow or integration publishes an event; any number of subscribers, inside or outside the org, react to it independently. It is not a record and leaves no row behind unless a subscriber writes one. In a build, Platform Events decouple checkout from enrollment creation and SIS notification, so a slow SIS cannot slow a learner's receipt. The Flow-first automation article explains when to publish an event and when a flow is enough.

Lightning Web Component

A Lightning Web Component, LWC, is Salesforce's standards-based UI component model built on web components and JavaScript. It is not Aura, the older framework, and not Visualforce. In a Commerce on Core build, LWCs are where custom front-end work belongs: a program finder, a gift designation picker, a cohort registration form. ElevateActual keeps record automation out of them, so a component can be replaced without touching enrollment logic. Accessibility testing of every custom component falls on the builder; see the WCAG checklist for LWR storefronts.

Select Partner

A Select Partner is a consulting firm holding the Select tier in the Salesforce Partner Program, assigned from Salesforce's partner scorecard, which counts certified staff and customer success measures among its inputs. ElevateActual is a Select Partner and is Education Cloud Accredited. The tier is not a statement about expertise in a specific industry; the accreditations and the delivered work are. It is also not a reseller designation; the institution buys licenses from Salesforce. The RFP committee article explains which questions the tier does and does not answer.

Summit Partner

A Summit Partner holds the highest tier in the Salesforce Partner Program, reached through the same scorecard at larger scale. It is not a guarantee that the people assigned to a university will have Education Cloud or Commerce experience, because tiers are awarded to the firm, not the team. It is not a procurement requirement unless an RFP makes it one. Ask for the named team's higher education references alongside the tier. The RFP committee article lists the questions that separate tier from fit.

Accelerator

An accelerator, in ElevateActual's usage, is a fixed-scope implementation of a defined slice of Education Cloud or Salesforce Commerce: a known list of deliverables, a timeline of about two months, structured discovery at the start, and the institution's own data and branding. It is not a managed package, and not a quick-start that stops at configuration without data or training. ElevateActual offers three: Commerce, Recruitment and Admissions, and Student Success. The accelerators page lists what each one includes and leaves out.

Staff Augmentation

Staff augmentation is a contract in which a partner supplies named people at an hourly or monthly rate to work inside the institution's team, usually without a fixed deliverable. It is not a project and not a managed service: a project is bought against a scope, augmentation against a rate and a term. In a Salesforce context it appears when a campus has an administrator and a roadmap but lacks a Commerce or Education Cloud specialist. The how we deliver page explains when ElevateActual recommends each model.

Higher Education Terms

The entries define the campus term and say which Salesforce record it meets. The continuing education page is where most of them come together.

Noncredit

Noncredit describes instruction that does not carry academic credit toward a degree: professional development, certificates, workforce training, community courses. It is not the same as continuing education, which at many institutions includes credit courses for adult learners. Noncredit registration is open, immediate, and paid at the time of registration, which is why it fits a storefront and why SIS registration flows fit it badly. In Education Cloud, noncredit programs use the same Learning objects as degrees. The continuing education page describes the storefront model built for it.

CEU (Continuing Education Unit)

A CEU is the standard unit for noncredit participation, commonly defined as ten contact hours of instruction under a recognized standard, and used by licensing boards and professional associations to count required learning. It is not a credit hour, and a CEU course does not transfer toward a degree. In Education Cloud, Continuing Education Units is an available duration unit on learning records, so a CEU program is modeled with the same objects as a degree. The continuing education data model article shows where the value is stored.

UPCEA

UPCEA, the University Professional and Continuing Education Association, is the professional association for leaders of online, professional, and continuing education units at colleges and universities. It is not a vendor and not an accreditor. It matters here because its members buy continuing education platforms, and because a 2023 report it published with Modern Campus found that many units struggle to get real-time enrollment data, as reported by UPCEA. The continuing education page starts from that problem.

Workforce Pell

Workforce Pell is the federal extension of Pell Grant eligibility to approved short-term workforce programs that fall below the length traditional Pell requires. Funding began July 1, 2026, with final rules still pending and many programs not yet qualified, as NPR reported through Michigan Public. It is not a general subsidy for noncredit. For a registration system it changes the data model: an eligible program needs approval status, hours, and outcome tracking that a plain storefront catalog never held. The community colleges article covers the records involved.

SIS (Student Information System)

The student information system is the campus system of record for admitted students, registration, grades, transcripts, and billing: Banner, Colleague, Jenzabar, or PeopleSoft. It is not a CRM, and Education Cloud is not an SIS, although both hold enrollment records; the difference is which one the registrar certifies. In a build, the SIS is integrated, never replaced, through supported APIs, staging tables, or middleware, and the integration design decides most of the project's risk. The SIS integration patterns article compares patterns by system.

LMS (Learning Management System)

The learning management system is where instruction happens online: Canvas, Blackboard, D2L Brightspace, Moodle. It is not the registration system and not the catalog, although Canvas Catalog bundles a storefront with the LMS. Education Cloud does not deliver courses, and a Salesforce storefront does not host content; after enrollment, the learner needs an LMS account and a course section, which is an integration. In a build, LMS provisioning is a post-purchase step triggered from the Course Offering Participant record. The Canvas Catalog and Salesforce article explains where each system should stop.

Banner

Banner is Ellucian's student information system, widely installed at public universities and community colleges, with Ethos as its integration layer and supported APIs for student, registration, and finance data. It is not a CRM and not a storefront; registration through Banner self-service assumes an admitted, term-activated student, which is why noncredit units route around it. In a build, Banner is integrated only through supported APIs, never direct database writes, which is how UNE Online's storefront was connected. See the SIS integration patterns article.

Colleague

Colleague is Ellucian's other student information system, common at smaller colleges and community colleges, with its own data model and the same Ethos integration layer that Banner uses. It is not Banner, and integration work does not transfer between them without rework. In a build, Colleague institutions tend to have smaller IT teams, so the integration design should favor approaches the campus can maintain: scheduled file exchange or a vendor-supported API over custom middleware. The SIS integration patterns article covers Colleague alongside Banner and Jenzabar.

Jenzabar

Jenzabar is an SIS vendor serving private colleges and smaller universities with Jenzabar One, and its current noncredit product is Campus Marketplace, released in 2023. It is not Ellucian, and its integration options differ: staging tables and scheduled jobs are common, and that is the pattern the health-sciences university admissions project used so that admitted students are no longer re-keyed. The SIS integration patterns article describes the staging-table pattern.

Enrollment Cliff

The enrollment cliff is the projected decline in the number of traditional college-age students in the United States, following the drop in births after 2008 and arriving at campuses in the second half of the 2020s. It matters here because it is the stated reason many institutions are investing in adult, online, and noncredit programs, and therefore in registration and storefront systems for learners who never enter the traditional funnel. The admissions page and the continuing education page describe the two responses.

Questions We Hear