- Institution
- University of Denver
- Platform name
- DU Learning Exchange
- First unit
- Center for World Languages and Cultures
- Built on
- Commerce on Core and Education Cloud, in DU's existing org
- Timeline
- Kickoff June 2026, UAT signed September 2026, in production September 2026
- Status
- Launching; DU is completing identity and SIS integration steps
The University of Denver chose to sell continuing education through a single transactional storefront, DU Learning Exchange, built on Commerce on Core inside the Salesforce org the university already owns. ElevateActual delivered the first unit's storefront from a June 2026 kickoff to production in September 2026. DU is completing its identity and SIS integration steps before opening it to the public.
Who DU Is and What They Wanted
The University of Denver is a private research university with several units that sell continuing education, from world languages and cultures to professional studies. Each unit had its own way of taking registrations, and the university's marketing team cared a great deal about how anything DU-branded looked and behaved on the web.
The ask was specific. Build one storefront that any unit can sell through, keep the marketing of programs on du.edu where University Relations controls it, make the registrar's office the owner of the storefront, and do it inside the Salesforce org DU already runs rather than standing up something new. The first unit would be the Center for World Languages and Cultures, with three more units queued behind it.
What We Built
| Decision | What DU Learning Exchange does | Why |
|---|---|---|
| Transactional only | The storefront sells. Program marketing stays on du.edu, with deep links from campaigns into the exact course. | University Relations keeps brand control; the storefront keeps checkout simple |
| Home redirects | The storefront root sends visitors to the default category rather than a marketing home page. | There is nothing to maintain twice |
| Unit administrators manage content | Course descriptions, dates, and prices live on Salesforce fields the unit edits. | No developer in the loop for a date change |
| Commerce Admin permission set | Storefront staff get a scoped permission set, not system administrator. | Least privilege in a shared university org |
| Standard objects for waitlists and capacity | Course Offering Participant records and standard capacity fields, not custom duplicates. | Phase two's automatic enrollment from waitlists needs nothing new |
| Measurement and consent | GA4 for attribution and a cookie consent banner, both validated with a live network trace before launch. | Institutional scrutiny of tracking deserves proof, not assurances |
| Payments | Salesforce Payments, with a pay-now path planned for internal group registrations. | One receipt and refund model across units |
The Design Decisions That Mattered
- Build inside the org DU owns. Sharing an org with the university's own builders means agreeing on record ownership, a dedicated service account for automation, and a named sender address so learners are not confused about which school is emailing them. We designed those first.
- Refuse to read custom duplicates. The org had custom fields that duplicated standard capacity data. The storefront reads the standard fields only, so phase two can automate waitlists on Education Cloud without reconciling two numbers. This is the standard-first rule in practice.
- A production hot test is mandatory. Commerce sites do not move from sandbox to production as one deployment, so we rebuild in production and then run a real purchase and a real refund two to three days before the public date. The launch checklist we use came out of projects like this one.
What Went Sideways
The production hot test did its job. The first real test purchase surfaced a missing default tax category, which stops checkout with an unhelpful Apex error, and a payment capture setting that needed to change before a refund would reconcile cleanly. Both were fixed the same day. They are now the first two lines on our tax, refunds, and receipts checklist.
The launch date also moved. The storefront was in production in September 2026, but public opening depends on DU-owned steps: single sign-on for existing DU users and the integration that reconciles orders to the student information system. We would rather report that plainly than call a storefront live before learners can use it.
What Is Next
Public launch follows DU's identity and integration validation. Three more units are planned to join the storefront, and a second phase adds group registration for small buyer-facing groups and larger internal ones, plus waitlists with automatic enrollment when a seat opens. Because the first unit was built on standard objects, adding a unit is configuration, not a new project.
Questions We Hear
Is DU Learning Exchange live?
Not yet, as of October 2026. The storefront is built, accepted, and deployed to production. The University of Denver is completing single sign-on and SIS integration steps before opening it to the public. We will update this page when it opens.
Why keep marketing on du.edu instead of the storefront?
Because the people who own the brand already have a website. A transactional storefront with deep links from campaigns gives University Relations control of the story and gives the registrar control of the sale.
How long did the first unit take?
Kickoff in June 2026 to production in September 2026, about three and a half months including integration work and the production hot test. The storefront itself follows our two-month Commerce Accelerator pattern.
Can several schools share one storefront without confusing learners?
Yes, with a few deliberate choices: one sender address for receipts, category pages per unit, unit-owned content fields, and a permission set that scopes what each unit's staff can change.
What is a production hot test?
A real purchase with a real card and a real refund in the production storefront, two to three days before the public date, with the finance office watching the result land. It finds the configuration gaps that sandboxes cannot.