Community colleges run more noncredit, workforce, and contract-training activity than any other part of higher education, and much of it still registers through spreadsheets or an aging catalog tool. A Salesforce storefront connected to Education Cloud gives a workforce division one catalog, one checkout, and one learner record. ElevateActual phases the work so each phase stays below the procurement threshold.

Why Are Community Colleges the Natural Home of Noncredit Commerce?

A community college sells more kinds of learning to more kinds of buyers than any university. In one week on one campus you will find a welding certificate paid for by a county workforce board, a nursing assistant refresher paid for by the student, a summer coding camp paid for by a parent, a dual enrollment section billed to a school district, and a forklift safety class billed to an employer under a contract-training agreement. Each has a different payer, approval path, and record.

The credit side of the college has a student information system for this. The noncredit side usually does not. Across the workforce divisions we have worked with, the pattern is a registration tool bought for open-enrollment classes a decade ago, a spreadsheet for contract training, a PDF form for camps, and a shared inbox for employer invoices. TheModern Campus and UPCEA survey of continuing education leaders found nearly half of units struggle to get real-time enrollment data.

Two things make 2026 the year to fix this. Workforce Pell funding began on July 1, 2026, with final rules still pending, so short-term workforce programs will need enrollment, attendance, and completion records that can be reported rather than reconstructed. And the decline in traditional-age students is pushing every college to grow the adult and employer side of the house. The noncredit storefront is where that growth is transacted. Our continuing education practice covers the general case; this article covers what is different for a community college.

What Does a Salesforce Storefront Plus Education Cloud Give a Workforce Division?

We build what we call Commerce on Core: B2B or D2C Commerce on the Salesforce Platform, an LWR Experience Cloud storefront, standard Order Summary records, Person Accounts for learners, and a connection to the Education Cloud objects (Course Offering, Course Offering Participant, Learning Program) so that enrollment is created at checkout. It is the standard Salesforce Commerce product configured to sell courses instead of goods. Our guide to Salesforce Commerce for higher education explains the stack. For a workforce division, it gives four things.

  • One catalog for every buyer. Open-enrollment certificates, camps, dual enrollment sections, and employer cohorts are all Course Offerings under a Learning Program. The storefront shows public offerings to the public and contracted offerings only to the employer's buyer group, at the employer's price. Education Cloud uses the same objects for continuing education as for degree programs.
  • Checkout that fits the payer. A learner pays by card. An employer buys ten seats on one order and assigns names later. A workforce board is invoiced after the fact, with the order recorded now. The campus payment processor stays; the storefront integrates with TouchNet or Transact CashNet through hosted checkout, or runs Salesforce Payments with Stripe. Our article on how universities take payments on a Salesforce storefront covers each pattern.
  • A learner record that persists. The person who took the nursing assistant refresher in March is the same Person Account who registers for phlebotomy in September. CourseOfferingParticipant records hold attendance and completion status, which is what Workforce Pell reporting will need.
  • Administration by the division, not by IT. Coordinators publish a section, set a price, and open registration from Salesforce fields under a Commerce Admin permission set, which removes most of the ticket traffic between the division and central IT.

What Is the Procurement Reality for a Community College?

Many state community college systems set a dollar threshold above which a purchase requires a formal procurement: a public solicitation, a board vote, or both. Below it, a college can contract directly on a quote or a short-form agreement. We will not quote a figure, because the number is yours to confirm with your purchasing office, and it changes.

The threshold is not an obstacle to route around. It is a design constraint, and a useful one. A project that respects it is phased into deliverables that each stand alone, each priced below the threshold, each with a written scope boundary. The college gets a working product at the end of every phase. If phase one is all the budget allows this year, phase one is still a storefront that sells courses. Three rules keep this honest.

  • Each phase is a complete deliverable, not a payment installment. Splitting one scope into three invoices is exactly what purchasing offices are trained to catch. Each phase has its own discovery, acceptance criteria, and go-live.
  • The scope boundary is written before the phase starts. The statement of work names what the phase does not include, so the next phase is a new decision rather than an assumed continuation.
  • The board cadence is respected. If the board approves contracts above a certain size at a monthly meeting, the calendar is built around that date. We have waited a month for a board meeting more than once. It is cheaper than the alternative.

Salesforce licensing is a separate purchase from Salesforce, often through a state contract or cooperative. Our fixed-scope accelerators were designed for this structure, and the Commerce accelerator is the usual phase one.

What Goes Live in Each Phase?

Storefront first, because the division can see it and the revenue depends on it. SIS handoff second, because it needs the most college-side decisions. Marketing and student success third, because both depend on the learner records the first two phases create.

PhaseWhat goes liveWhat it does not include
Phase one: storefront and checkoutPublic LWR storefront on the college's domain; noncredit Course Offerings under Learning Programs; checkout against the campus payment processor or Salesforce Payments; Person Account and Course Offering Participant created at purchase; receipts; Commerce Admin permission set and coordinator trainingSIS integration; employer buyer groups beyond one pilot employer; marketing automation; waitlists with automatic enrollment; advising or alerts
Phase two: SIS handoffHandoff of completed enrollments to Banner, Colleague, Jenzabar, or PeopleSoft through supported APIs or a staging table; student ID write-back; employer buyer groups and contract pricing; group registration; waitlistsCredit-side records; financial aid; marketing; student success; degree audit
Phase three: marketing and student successMarketing Cloud or Account Engagement campaigns from storefront behavior; Education Cloud alerts and success plans for workforce cohorts; case management for employer and workforce board inquiries; reporting for Workforce Pell and grant fundersStorefronts for additional colleges in the district (each its own phase); advancement; Agentforce

Phase One: Storefront and Checkout

Phase one ends when a learner can find a course, pay, and receive a receipt, and the enrollment appears in Salesforce. It takes about two months from discovery to go-live. The hard decisions are not technical: which programs go into the first catalog, who approves prices, and whether the division keeps the existing payment processor. We settle those in discovery, in writing.

Phase Two: SIS Handoff

Phase two moves the completed enrollment into the system of record, usually one way, with the student ID coming back. We integrate only through supported APIs or a staging table the SIS team owns, never direct database writes. Our article on SIS integration patterns for Banner, Colleague, and Jenzabar covers the choices. If the college is leaving Lumens or CampusCE at the same time, our migration guides describe what moves and what stays.

Phase Three: Marketing and Student Success

Phase three is where the learner record starts paying for itself. A completion becomes a nudge toward the next stackable credential, a workforce-board cohort gets an alert when attendance drops, and the employer who bought ten seats gets a case queue instead of an inbox.

What About a Multi-College District?

Most community colleges belong to a district or state system, and the first architecture question is whether the district buys one Salesforce org or each college buys its own. Our answer, in almost every case, is one org and many storefronts. Salesforce Commerce supports multiple storefronts in one org, each with its own domain, branding, catalog, and payment configuration, so each college keeps its identity while the district keeps the data in one place. Our pillar guide to Salesforce for higher education covers the org question for the credit side. The shared catalog question is the one to decide early. Three patterns work.

  • Separate catalogs. Each college owns its Learning Programs and Course Offerings. Right when the colleges run different programs.
  • Shared programs, local offerings. The district defines the Learning Program once, and each college publishes its own Course Offerings under it with local dates, instructors, and rooms. Reporting rolls up by program. We recommend this when the district reports to a state board by program.
  • One district storefront. One public catalog filtered by college and location. It only works when the colleges accept shared branding, and most do not.

Whichever you choose, each additional college storefront is its own phase with its own scope boundary. The colleges that move first will own the workforce relationships in their region by the time the Workforce Pell rules settle. The storefront is a smaller project than it looks, provided it is phased the way the district already buys.

Questions We Hear

Is Salesforce a good fit for community colleges?

Yes, when the college treats noncredit and workforce as a business with buyers, orders, and learner records rather than a catalog that needs a website. Education Cloud models continuing education with the same objects as degree programs, Salesforce Commerce sells seats with real checkout, and one org can serve every college in a district. It is a poor fit for a college that only wants a brochure site with a registration form.

Can we buy below our procurement threshold?

In most systems, yes, as long as each phase is a complete deliverable with its own scope and acceptance, not one project split into installments. We write each phase as a standalone statement of work that names what it does not include, and we build the calendar around your board's approval cadence. Confirm the threshold with your purchasing office before discovery; it varies by state and district, and we do not publish figures.

Do we need Education Cloud, or can the storefront run on Salesforce alone?

The storefront can run on Salesforce Commerce without Education Cloud, and some colleges start there. Education Cloud adds the learner record: Learning Programs, Course Offerings, and Course Offering Participants that carry attendance and completion, which is what workforce boards, grant funders, and Workforce Pell reporting ask for. We recommend licensing Education Cloud in phase one so the records are right from the first sale.

We already have a noncredit registration system. Why change?

If it registers learners, takes payment, reports completions, and your coordinators can run it without IT, keep it. The colleges that come to us have a tool that does one of those well and the rest through workarounds: contract training in a spreadsheet, camps on a PDF, employer invoices in an inbox. The case for change is one learner record and one checkout across all of it, administered by the division.

How long does phase one take?

About two months from discovery to a live storefront, for one college with a noncredit catalog, one payment method, and coordinators trained to publish sections. Discovery takes the first two to three weeks and settles the catalog scope, the payment path, and the acceptance criteria in writing. Build, user acceptance testing, and a production hot test fill the rest. SIS handoff is a separate phase with its own timeline.