Canvas Catalog and Salesforce are complements, not rivals. Canvas stays as the LMS. Salesforce takes the catalog, checkout, and learner record, then hands the enrollment to Canvas. The move suits a unit that has outgrown Catalog's storefront and wants a CRM behind it. ElevateActual builds the handoff in Flow and tests it with a real purchase in production.
What Does Canvas Catalog Do?
The first thing people trip over is the name. Canvas Catalog is not Canvas. Canvas is the LMS, where the course content and the teaching happen. Catalog is a white-label storefront and registration layer that Instructure launched in May 2014 to sit in front of Canvas. Instructure itself was taken private by KKR and Dragoneer in November 2024.
Catalog's product page describes a branded course listing, self-service registration, payment collection, certificates, programs and bundles, and revenue and enrollment reports. Its strength is that it is already wired to Canvas: a learner who registers in Catalog lands in the Canvas course without anyone touching a spreadsheet. If your unit is small, the catalog is short, and nobody needs a CRM, that is a perfectly good arrangement, and nothing on this page should talk you out of it.
Its limits show up on the commerce side. Some users on the Instructure community report that Catalog supports a fixed list of payment gateways and that running more than one gateway means splitting into subcatalogs by domain. Those are community threads, not a review site, so check them against the current release before you plan around them.
Why Do Teams Add Salesforce Beside Canvas?
The honest framing is a split of jobs. Canvas keeps teaching. Salesforce takes selling and remembering. A continuing education storefront on Salesforce owns the public catalog, the cart, the checkout, and the learner record, and Canvas receives the enrollment.
Catalog is a storefront, not a CRM. It knows who registered. It does not know who inquired and never registered, who called support twice, who bought from two other units, or who should get the certificate email in March. With Salesforce Commerce for higher education, those are all one Person Account with an order history, a case history, and a marketing consent.
The campus payment processor. A university bursar usually requires TouchNet or Transact CashNet. On Salesforce, checkout hands off to that processor's hosted page and the result writes back to the order. Catalog's gateway list may or may not include what your bursar requires; that is a question for the Instructure community thread and your bursar, and it is often what starts this conversation.
One storefront for units that are not on Canvas. The conference, the camp, the executive program with a different LMS, the gift to the foundation: a Salesforce storefront sells them from the same cart. Catalog sells what Canvas teaches.
The institution is standardizing on Salesforce. If admissions and advancement already live there, the continuing education learner joining them is an institutional decision rather than a unit one. That distinction matters later on this page.
What Moves and What Stays?
Read the Canvas row first. It does not change. Everything in front of it does.
| Data or capability in Canvas Catalog | Where it goes in Salesforce | Notes |
|---|---|---|
| Canvas courses and teaching | Stays in Canvas | Nothing about the course shell, content, or grading changes. |
| Public course listing and landing pages | Commerce on Core storefront, products and categories | Branding is yours in Experience Builder. |
| Programs and bundles | LearningProgram plus Commerce bundles | Mapped in the catalog workshop. |
| Course listings tied to Canvas course IDs | CourseOffering with the Canvas course identifier stored on it | This field is what the handoff keys on. |
| Registrant profiles | Person Accounts | Matching on email and campus ID agreed before the first load. |
| Registration history and certificates | CourseOfferingParticipant | Historical certificates archived; new ones generated from Salesforce. |
| Checkout and payment | Commerce checkout with the campus processor or Salesforce Payments | Salesforce integrates with TouchNet or Transact CashNet; it does not replace them. |
| Enrollment into the Canvas course | Flow and Platform Event on the enrollment record, calling Canvas's API | The handoff is a build we test with a real purchase. |
| Drops and refunds | Order change in Salesforce; unenrollment sent to Canvas | Refund money moves where the payment was taken. |
| Revenue and enrollment reports | Salesforce reports and dashboards | Finance gets Order Summary data without an export. |
| Canvas user accounts | Stays in Canvas; created or matched by the integration | Identity provider rules decided with IT, not the unit. |
| SIS, if enrollments post to one | Stays as system of record | Supported APIs only; never direct database writes. |
What Does the Salesforce Side Look Like?
Commerce on Core is ElevateActual's term for B2B and D2C Commerce built on the Salesforce Platform with an LWR Experience Cloud storefront. It is not B2C Commerce, the former Demandware stack. Every purchase creates an Order Summary and Order Item Summary record, which is what finance and marketing read.
Education Cloud (Agentforce Education) supplies the learning model. Salesforce documents the program and offering objects, and continuing education uses the same objects as degree programs. Each CourseOffering carries the Canvas course identifier. Checkout creates the CourseOfferingParticipant record, and that record is where the handoff lives.
Here is where the setting sits, because someone will ask. A record-triggered Flow on CourseOfferingParticipant publishes a Platform Event when the status becomes enrolled. A subscriber calls Canvas's API to find or create the user and enroll them in the course whose identifier is on the offering. A drop runs the same path in reverse. There is no Apex in that chain unless the platform requires it, which it usually does not. The Flow-first automation article explains why we build it that way.
Payments follow one of two patterns we have built: Salesforce Payments with Stripe, or a hosted checkout handoff to Transact CashNet or TouchNet with a post-authorization adapter writing the result to the order. Refunds and receipts are their own topic; the tax, refunds, and receipts article covers it. Our house demonstration storefront, ElevateActual University, shows the storefront side with 50 programs, seven categories, one cart, and guest checkout.
How Do We Run the Move?
- Discovery. Program staff, finance, marketing, the Canvas administrator, and whoever owns identity. The Canvas administrator is in the room from day one; this is not a unit-only project.
- Catalog mapping. A workshop that maps Catalog listings, programs, and bundles to the learning objects and the Commerce product and price book, and records the Canvas course identifier for each.
- Build the storefront on your own programs. Not sample data.
- Build and test the handoff. The Flow, the Platform Event, and the Canvas API call, tested against a Canvas test instance before anyone sees production.
- Delta loads. Registrants and history load in waves while Catalog keeps running. No data freeze.
- Parallel period. Catalog finishes the current term while the Salesforce storefront opens the next. Both deliver enrollments into the same Canvas, which is a nice property of keeping the LMS.
- Cutover and the production hot test. Catalog URLs redirect, Catalog registration closes, and your staff buy a real course with a real card in production, confirm the Canvas enrollment and the receipt, then drop and refund it. The storefront is live when that passes.
Our Commerce accelerator reaches production in about two months for a unit starting fresh. Adding the Canvas handoff and history adds time, so plan in months. The UAT and go-live article describes the acceptance steps.
When Should You Leave Catalog Where It Is?
If every course you sell is a Canvas course, your gateway works with your bursar, your catalog fits on one page, and nobody has asked for a CRM, keep Catalog. It does the one thing you need and it does it with Instructure's support behind it. A storefront on Salesforce would give you a better cart and a learner record you do not yet have a use for.
Now the unit versus institution distinction. Whether to move the storefront is a unit decision; the unit owns the catalog and the revenue. Whether Salesforce holds the learner record for the whole institution is not a unit decision, and a unit should not make it alone, because identity, the SIS, and the payment processor all belong to someone else. If the institution has not decided, the unit should ask before it buys.
Move when the unit sells things Canvas does not teach, when the bursar's processor is not on Catalog's list, or when the institution has decided learners live in Salesforce. Canvas stays either way. Our migration guides cover the registration systems that sit beside it.
Questions We Hear
Do we have to leave Canvas to use Salesforce?
No, and please do not. Canvas stays as the LMS, with its courses, content, and grading untouched. Salesforce takes the public catalog, the checkout, and the learner record, then creates the Canvas enrollment through Canvas's API when the purchase completes. Catalog is the piece that is replaced, not Canvas. If anyone describes this move as an LMS migration, they have misread it.
How does the learner get into the Canvas course after checkout?
A record-triggered Flow on the Course Offering Participant record publishes a Platform Event when the status becomes enrolled. A subscriber calls Canvas's API to find or create the user and enroll them in the course whose identifier is stored on the Course Offering. We test it first against a Canvas test instance and then with a real purchase in production before opening.
What happens on a drop or a refund?
The order is changed in Salesforce, the refund is issued where the payment was taken, the processor or Salesforce Payments, and the same integration sends an unenrollment to Canvas. Whether a drop automatically unenrolls, or waits for a staff decision, is a unit rule we set in a Flow, and it is one of the questions discovery asks early.
Does Salesforce replace TouchNet or Transact CashNet?
No. The campus payment processor stays, and Salesforce integrates with it through a hosted checkout handoff with a signed request and a write-back to the order. Where the institution has no processor requirement, Salesforce Payments with Stripe is the other pattern we have built. If your bursar's processor is the reason Catalog is awkward, this is usually the part of the move that makes the bursar happy.
Who owns the Canvas integration after go-live?
The Flow and Platform Event live in the Salesforce org and belong to whoever administers it. The Canvas side, the API credentials and the developer key, belongs to the Canvas administrator. We document both, train both, and write down which changes are the unit's to make and which need IT. That handoff of ownership is part of the delivery, not an afterthought.