UAT and Go-Live for a University Storefront: The Checklist We Run

A university storefront launches cleanly when UAT runs by persona with office hours, acceptance is signed, production is rebuilt with time to spare, a real card and a real refund are tested two or three days before launch, and launch week has a named owner for every task. ElevateActual runs the same checklist on every storefront.

What Does UAT Cover?

User acceptance testing proves the storefront works for the people who will use it. We write the scripts by persona, and each persona gets its own tester from the institution. The storefront is what we call Commerce on Core: B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront, connected to Education Cloud so that checkout creates the enrollment. The Commerce Accelerator ships with these scripts.

• Guest learner. Find a course from the home page and from search. Add to cart. Check out without an account. Receive the receipt and the enrollment confirmation.
• Returning learner. Sign in. See order history and enrollments. Register for a second course. Apply a promotion code. Request a refund.
• Staff publisher. Create a course offering in Salesforce with price, dates, capacity, and instructor. Publish it. Confirm it appears in the right category.
• Registrar. Find the learner created by a guest checkout. Confirm the CourseOfferingParticipant record and the roster report. Confirm the waitlist at capacity.
• Finance. Trace one order from checkout to the processor to the order record to the receipt. Process one refund. Confirm the tax line and the settlement report.

Every step has a pass or fail box and space for the tester's note. No step is marked pass by us.

How Do Office Hours Work During UAT?

UAT runs two to three weeks. We hold office hours three times a week at a fixed time. Testers bring failures and questions. We fix what can be fixed in the session, log what cannot, and show the fix at the next session. Defects go into one shared list: what happened, who saw it, severity, status. Severity has three levels. Blocks launch. Fix before launch if time allows. Fix after launch. The institution's project lead assigns the level, not us.

What Does Signed Acceptance Look Like?

UAT ends with a document, not a meeting. The acceptance lists every script, the tester, the pass count, the open defects by severity, and the agreed disposition of each. The institution's project sponsor signs it. We countersign. After signature, a new request is a change, not a defect, and the production clock starts. University of Denver's DU Learning Exchange followed this sequence: user acceptance signed in September 2026, deployment to production in September 2026, launch sequenced behind DU's identity and SIS integration steps. The DU Learning Exchange case study covers the design choices.

Why Is Production a Rebuild, Not a Deploy?

A Commerce storefront does not move from sandbox to production as one deployable unit. In our experience, parts deploy and parts are rebuilt:

• The store record, its tax and payment integrations, buyer groups, entitlement policies, and the search index are configured in production by hand or by script.
• Products, prices, categories, and images are loaded with data tools against production IDs.
• Site pages, theme, and custom components deploy piecewise, with verification after each piece; Flows, permission sets, and Education Cloud configuration deploy through the normal metadata path.

Plan two to three weeks between signed acceptance and launch for the rebuild and its verification. Not two days. The implementation timeline by scope shows where this window sits. After the rebuild, the UAT scripts run again in production, abbreviated: same testers, one pass each.

What Is the Production Hot Test?

Two or three days before launch, one person from finance and one from ElevateActual run the hot test in production:

1. Buy the cheapest real course with a real card belonging to a staff member.
2. Confirm the order record, the enrollment record, the receipt email, and the processor entry.
3. Refund the order in full through the storefront's refund path.
4. Confirm the refund on the order, in the processor, and on the card statement when it posts.
5. Confirm the tax line on both the sale and the refund.

Test cards do not count. The hot test proves the production merchant account, tax setup, and receipt flow work with real money. The refund matters as much as the sale; tax, refunds, and receipts is where storefronts fail quietly. Two or three days leaves time to fix a merchant account setting. Launch morning leaves none.

Who Is on the Launch-Week Roster?

Every launch task has one owner and one date. The owner is the institution or ElevateActual. Never both.

What About Out-of-Office Risk?

A launch week with a key person on vacation is a launch week with no owner for that person's tasks. We check calendars for every roster name before the launch date is fixed. Two rules. Every roster name has a named backup who sat in at least one UAT session. Launch does not land in the week before a holiday, the first week of a term, or an IT change freeze. If the date must move, move the date.

What Do Learners See If Single Sign-On Lands After Launch?

Institutional single sign-on often finishes after the storefront, because campus identity teams have their own queues. The storefront can launch first with interim messaging, agreed in writing:

• The sign-in page says, in plain words, that learners create a storefront account with their email for now and that campus sign-in is coming.
• Receipt and confirmation emails use the same wording, and support staff have a one-paragraph answer ready.
• The plan for linking interim accounts to campus identities is written before launch, because it depends on the identity key decided during migration.

Interim messaging is a launch task with an owner, not a note in a meeting.

Why Does the Daily Email Limit Matter?

Salesforce caps the single emails an org can send each day through Flow, Apex, and the API. The cap is documented on Salesforce Help, varies by edition, and resets at midnight GMT; sandboxes have much lower caps than production. Two consequences. A load test or bulk re-send during UAT can exhaust the cap, after which receipts silently stop, so the receipt flow needs a switch that lets testing run without sending. Check this during the rebuild, not on launch day.

What Happens the Day After?

The day-after review takes thirty minutes. The institution's project lead runs it:

1. Orders placed, by hour. Failed checkouts, with cause.
2. Support questions, grouped: messaging fixes versus defects.
3. Receipts and confirmations sent against orders placed. Any gap.
4. Processor settlement against order totals.
5. Open defects marked fix after launch, now scheduled.

The same review runs at one week and at one month. After the one-month review, the storefront moves to the ongoing arrangement described in how we deliver.

What Is Out of Scope for Launch Week?

Launch week is for launching. These are not launch-week work, and the roster says so:

• New products, categories, or pages requested after signed acceptance.
• Design changes to the theme or page layouts.
• New promotions or pricing rules not tested in UAT.
• Single sign-on, if not ready at acceptance; it follows its own plan.
• Real-time SIS integration, if the interim file is the agreed launch state.
• Phase two features such as group registration, waitlist automation, or new payment methods.

Anything on this list raised during launch week goes on the phase two list with a date.

Questions We Hear