Yes. Salesforce Commerce sells university courses, certificate programs, and bundles when the storefront is connected to Education Cloud. A Course Offering becomes a product, term and modality become variation attributes, and checkout creates the Course Offering Participant that enrolls the learner. ElevateActual has built this for public and private universities and runs a demonstration storefront anyone can try.
How Does a Course Become a Product?
In Education Cloud (Agentforce Education), the academic side of a course lives in standard objects: a LearningProgram for the certificate or program, a LearningCourse for the course itself, a CourseOffering for a specific run of that course in an AcademicTerm, and a CourseOfferingParticipant for each learner enrolled in that run. Salesforce Help describes continuing education programs using the same objects as degree programs, and that is how we model them.
Salesforce Commerce sells from a different set of objects: Product2, PricebookEntry, and ProductCategory. The storefront we build, which ElevateActual calls Commerce on Core (B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront), joins the two. Each sellable course is a product that points at its Course Offering. The learner shops the product. The enrollment is written to the Course Offering.
The useful part is variations. A course that runs in the fall and spring terms, in two sections, online and in person, is one product with three variation attributes: term, section, and modality. The learner picks the combination on one product page and the storefront resolves it to the matching Course Offering. The unit maintains one product page per course instead of one per run, and the category pages stay readable. The Education Cloud data model for continuing education walks through the mapping object by object, and the guide to Salesforce Commerce for higher education places it in the full architecture.
What Happens at Checkout?
When the learner pays, Salesforce Commerce writes an OrderSummary with one OrderItemSummary per line. From there, Flow does the work. On the storefronts we have built, a record-triggered flow on the paid order reads each line, finds the Course Offering behind the product variation, creates the CourseOfferingParticipant for the learner, and sets its status. If the course belongs to a program the learner has not started, the same flow can create the program enrollment. The learner receives an order confirmation email and sees the course on their account page.
Three details matter. The enrollment is created only when the order is paid, not when the cart is created, so abandoned carts leave nothing behind. Capacity is checked against the Course Offering before the seat is granted, so an oversold section becomes a waitlist record instead of a quiet overage. And the automation lives in Flow, which an administrator can read and adjust, with Apex reserved for the few places the platform requires it, such as a payment adapter or a tax calculator.
Guest or Registered Learners?
Both, and most storefronts need both. A guest learner checks out with an email address and no login. The storefront still needs a person record to enroll, so the post-purchase automation matches the guest to an existing Person Account by email and name, or creates one. A registered learner signs in, sees prior orders and enrollments, and checks out faster. The choice is about the unit's audience: a community workshop audience buys as guests, and a professional certificate audience returns and wants an account.
Person Accounts are the learner record in Education Cloud, and the storefront uses them directly. There is no separate shopper table to reconcile. A learner who applied through admissions and later buys a noncredit course is one record, which is the point of building the storefront on the same platform as the rest of the institution.
How Are Certificates and Bundles Sold?
A certificate program is a LearningProgram made of Learning Courses. It can be sold two ways. Sell the program as one product, and checkout creates the program enrollment plus the participant records for the first required course offerings. Or sell each course separately and let the program enrollment accumulate as the learner completes courses. Units with a fixed cohort sequence usually sell the program. Units with a pick-your-path certificate sell courses.
A bundle is a Commerce product that groups other products at one price, for example a three-course sequence sold together, and checkout creates one participant record per course inside it. Unity Environmental University's public storefront at learn.unity.edu sells Distance Education courses and bundles on Education Cloud and Salesforce Commerce, with post-purchase automation that creates the Person Account, application, and enrollment records.
What a Continuing Education Unit Sells and How It Is Modeled
| Thing a CE unit sells | How it is modeled | What is created at checkout |
|---|---|---|
| Course section | A product with variation attributes for term, section, and modality, each variation pointing at a Course Offering | A Course Offering Participant for the learner |
| Certificate program | A product pointing at a Learning Program | A program enrollment plus participant records for the required offerings |
| Bundle | A Commerce bundle of course products at one price | One Course Offering Participant per course in the bundle |
| Membership | A product with a term; renewal by a renewal order, or a subscription selling model where the org is licensed for it | A membership record with start and end dates, and a buyer group assignment for member pricing |
| Camp | A Course Offering bought by a guardian for a minor | A Course Offering Participant for the child, linked to the paying parent's Person Account |
| Corporate cohort seat | A B2B buyer group with account-level pricing; the company's buyer purchases a quantity | Participant records per named learner, or a seat allocation the company fills later |
| Gift | A designation product that accepts any amount | A gift transaction in Education Cloud's native Fundraising; no enrollment |
What the Storefront Is Not
The storefront is not the student information system. Credit enrollments, transcripts, and financial aid stay in Banner, Colleague, or Jenzabar. When a paid noncredit enrollment must also appear there, we integrate through supported APIs, never direct database writes. It is not the learning management system; Canvas or Moodle still delivers the course, and the enrollment record is what tells the LMS who is in it. And it is not the payment processor. Salesforce Payments with Stripe is a native option, but on most campuses the storefront hands the learner to TouchNet or Transact CashNet for the card step and receives the result back. Salesforce sits beside those systems rather than replacing them.
Where Can I See It Working?
ElevateActual University, our house demonstration storefront at demo.elevateactual.com/eau, sells fifty programs across seven categories through one cart with guest checkout. It is described on the see it live page, and it is the fastest way to test the claim in the headline. For a production example, UNE Online replaced an EDA plus Enrollment Rx storefront with Education Cloud and Commerce on Core and went live for fall 2026 enrollment. The continuing education commerce page explains what a project to get there looks like. The next storefronts we build will follow the same mapping, because it has held up across every catalog we have put through it.
Questions We Hear
Do we need Education Cloud to sell courses on Salesforce Commerce?
Commerce can sell a product on its own, but the enrollment then has nowhere standard to live. With Education Cloud, checkout creates a Course Offering Participant on a Person Account, which is the record advisors, instructors, and reports already use. If the institution runs EDA rather than Education Cloud, talk to us before deciding; the storefront pattern is the same but the learner-record objects differ.
Can a learner buy a course for someone else?
Yes, with a design decision. A parent buying a camp seat for a child, or a manager buying seats for a team, is a purchaser who is not the participant. The storefront collects the participant's details at checkout or afterward, and the flow creates the participant record for the right person. Education Cloud's Delegated Access supports the parent and guardian case.
Does checkout enforce prerequisites and capacity?
Capacity, yes: the flow checks the Course Offering before granting a seat and creates a waitlist record when the section is full. Prerequisites can be enforced at checkout or at add-to-cart, but enforcing them before purchase requires a custom component and a signed-in learner, so many units state prerequisites on the product page and verify after purchase instead.
Is this B2C Commerce, the former Demandware product?
No. B2C Commerce is a separate stack we do not use for higher education. Commerce on Core is B2B or D2C Commerce on the Salesforce Platform, where the order, the Person Account, and the Course Offering Participant are records in the same org as Education Cloud. That shared database is what makes enrollment at checkout a flow rather than an integration.
Can we sell continuing education units and record completion?
Yes. The Course Offering Participant record carries the learner's status through enrolled, completed, or withdrawn, and the Course Offering carries the credit or unit value. Completion is recorded on the participant record by the instructor or by an LMS integration, and a certificate or badge issuer can read it from there. The storefront's job ends when the participant record exists.