Education Cloud Data Model for Continuing Education, Program to Participant

Education Cloud models continuing education with the same objects it uses for degree programs. A LearningProgram holds the credential, a LearningCourse holds the course, a CourseOffering is one section in an AcademicTerm, and a CourseOfferingParticipant is the enrollment. A storefront sells Product2 records that point at those offerings. ElevateActual builds that mapping on every continuing education storefront.

Where Does a Continuing Education Unit Start?

A continuing education unit usually arrives with a catalog that lives in a registration system, a spreadsheet, or both. It has courses, sections of those courses that run in particular months, instructors, seat limits, prices, and a roster per section. Some courses stack into certificates. Many are noncredit, so the unit may not use the registrar's terms at all. Learners are often not students of record anywhere else on campus, and some return every year under a slightly different email address.

Education Cloud has a standard home for each of those things. Salesforce Help is explicit that continuing education programs, recreational programs, and degree programs use the same architectural building blocks, documented in Model Learning Program Offerings. The work is deciding which of your things is which standard object before the storefront is built, because the storefront inherits the catalog's shape. The rest of this page walks that chain in the order a continuing education unit on Salesforce meets it, then shows how the commerce objects attach.

What Is the Chain From Learning Program to Participant?

Every object below is standard, shipped with Education Cloud in API version 57.0 and later, and maintained by Salesforce in every release.

Learning, Learning Program, and Learning Course

Learning is the curriculum record: the thing you teach, independent of when or where you teach it. When you create a Learning, you decide whether it is represented as a LearningProgram or a LearningCourse, and you create that child record against it.

A LearningProgram is a group of learnings that leads to a credential. For a continuing education unit, that is the certificate: a project management certificate made of five courses, or a paralegal program made of eight. A LearningCourse is a single unit of teaching: one course in the catalog, whether it belongs to a certificate or stands alone as a one-day workshop. The LearningCourse carries CourseNumber, SubjectAbbreviation, FieldOfStudy, CourseLevelDescription, Duration, and DurationUnit.

Two details on these objects matter to a continuing education unit more than to a registrar. First, the DurationUnit picklist on Learning includes Continuing Education Units, Clock Hours, Credit Hours, and No Credit. The CEU decision is a picklist value, not a custom field. Second, LearningProgram has a standard Product2Id lookup. Salesforce shipped a direct link from a program to a sellable product, which tells you how the storefront is meant to attach.

Course Offering and Academic Term

A CourseOffering makes a LearningCourse concrete in time and place. It is the section. It carries the start and end dates, the lead instructor in PrimaryFacultyId, a SectionNumber, and the seat arithmetic: EnrollmentCapacity, EnrolleeCount, WaitlistCapacity, WaitlistCount, IsWaitlistActive, and AvailabilityStatus. Meeting patterns go on CourseOfferingSchedule records beneath it. Salesforce documents this layer in Model Courses and Curricula.

The offering sits in time through AcademicTerm, which holds StartDate, EndDate, RegistrationOpenDate, RegistrationCloseDate, LateRegistrationDate, and Season, and rolls up to an AcademicYear. An AcademicSession can subdivide a term for units that run shorter blocks inside it. Continuing education directors often tell us they have no terms. They have whatever window the storefront filters on and finance reports by, and that window is an AcademicTerm.

Course Offering Participant and Academic Term Enrollment

A CourseOfferingParticipant is one learner in one offering. It is the roster line, the record the storefront creates at checkout, and the record the instructor sees. It looks up to the learner through ParticipantContactId and ParticipantAccountId, and its ParticipationStatus picklist carries the whole lifecycle: In Cart, Enrolled, Waitlisted, Eligible to Enroll from Waitlist, Dropped, Withdrew, Completed, and several waitlist-offer states. The In Cart and Waitlist Enrollment Offer in Cart values exist because Salesforce designed the object with a shopping cart in mind. Salesforce describes the learner-facing side in course registration on a learner portal.

The outcome lives on a separate record, CourseOfferingPtcpResult, which carries LetterGrade, NumericGrade, UnitsEarned, and its own DurationUnit, including Continuing Education Units. That is where a CEU is earned, as opposed to offered.

AcademicTermEnrollment is the learner's enrollment in a term as a whole rather than in one section. It carries AcademicStanding and a link to the term's registration timeline, and each CourseOfferingParticipant can point to it through AcademicTermEnrollmentId. Degree programs need it. Most noncredit units do not, unless they report term-level activity or use holds and blocks that apply to a learner for a whole term.

Learner Pathway

LearnerPathway, available in API version 61.0 and later, is the learner's planned path to completing the programs they are enrolled in, with one LearnerPathwayItem per requirement. The requirement set itself is defined once on LearningProgramPlan and LearningProgramPlanRqmt; the pathway is the learner's copy of it with progress. For a certificate of five courses, the pathway is what answers "which two are left" without a spreadsheet.

The Learner as a Person Account

Education Cloud represents an individual as a Person Account: an Account with IsPersonAccount set to true that carries its own Contact. One learner is one Person Account, and that same record is the applicant in admissions, the donor in advancement, and the buyer on the storefront. Salesforce's Data Migration Kit converts EDA's account-and-contact pairs into Person Accounts for exactly this reason. A guest buyer still has to become a Person Account after purchase, and the matching rule for that is a design decision, not a default.

How Does a Storefront Map Onto the Model?

We build storefronts as Commerce on Core, ElevateActual's term for B2B and D2C Commerce built on the Salesforce Platform with an LWR Experience Cloud storefront, in the same org as Education Cloud. The commerce objects are standard platform objects that attach to the learning chain at specific points. Our overview of Salesforce Commerce for higher education covers the storefront itself; this section covers the joins.

• Product2 is the course. One product per LearningCourse, holding the title, description, and image. A certificate sold as a package is a product too, and LearningProgram.Product2Id already exists to hold that link. The product-to-course join for individual courses is the one place a custom lookup field is justified, with the reason written down.
• Product variation attributes are the section. Commerce on Core supports a variation parent with an attribute set. We use term, section, and modality as the attributes, and each variation product corresponds to one CourseOffering. The learner sees one course page and picks "Spring 2027, Section 2, Online" from it.
• Pricebook2 and PricebookEntry hold the price. The price lives on the PricebookEntry for each variation, not on the offering. Member pricing, employee pricing, or early-registration pricing are separate price books resolved by buyer group, which is why the offering record never needs a price field.
• ProductCategory is the navigation. Categories mirror the subject areas the unit markets by, which usually track the Category picklist on Learning.
• OrderSummary is the receipt. Checkout produces an Order, and Salesforce Order Management produces an OrderSummary with one OrderItemSummary per line. Each line references the variation product, which references the offering, which is everything the post-purchase automation needs to create the CourseOfferingParticipant. The question of whether Salesforce Commerce can sell university courses is really the question of whether this join is built.

Which Object Maps to Which?

What Is the One Trap?

The trap is modeling each section as its own product. The storefront search returns six copies of "Grant Writing Fundamentals," each with a term baked into the title. Category pages fill with near-duplicates. Last year's sections linger because nobody is sure which product is safe to deactivate. On the storefronts we have built, the product count roughly triples under this model and the search index gets noisy enough that learners stop trusting it.

The fix is the mapping above: one product per course, one variation per section, with term, section, and modality as the attributes. The category page shows one tile per course. The product page offers the choice. When a section ends, its variation stops being offered and the course stays where learners bookmarked it. One note from those builds: the guest profile needs field-level access to the attribute fields, or category pages containing variation parents render empty for anonymous shoppers.

What Should You Decide Before Building?

Three decisions shape everything downstream, and all three belong to the continuing education unit, not to the implementer.

1. Catalog shape. Confirm that the course is the parent and the section is the variation. Decide which attributes a learner actually chooses by (term, section, and modality cover nearly every unit we have worked with). Decide whether certificates are sold as packages, as individual courses, or both. Decide who maintains product content; on a well-built storefront, unit administrators edit Salesforce fields rather than the page builder.
2. What counts as a term for noncredit. Pick one convention: calendar quarters, named sessions, or a long open-enrollment term with AcademicSession records for rolling starts. The convention has to be something a learner can filter by on the storefront and something finance can group by at month end. Changing it after launch means re-keying every offering.
3. Whether CEUs are tracked. If yes, set DurationUnit to Continuing Education Units on the Learning, record UnitsEarned on CourseOfferingPtcpResult, and name who marks completion (the instructor, an LMS feed, or an administrator). If no, leave the fields alone and do not add a custom CEU field in case you want it later. Adding a standard value later is cheap; unwinding a custom field is not.

Two smaller decisions follow: whether the unit needs AcademicTermEnrollment, and what rule turns a guest buyer into a Person Account (email plus name, or a student ID when the learner has one). Settle those and the storefront build becomes configuration. Our standard-objects-first stance explains why we hold this line, and the glossary of Salesforce terms for higher education defines each object in one line for a committee.

Questions We Hear