Review and approve a Content Change
On this page
Every edit made to your storefront - whether a person made it in the Website Builder or an AI agent made it through your connected agent tools - is staged first as a Content Change in Salesforce. Nothing reaches your live site until a human reviews that Content Change and approves it.
This article covers where to find pending changes, what their statuses mean, how to inspect exactly what a change will do, and how to approve, reject, or edit it.
Where pending changes live
Content Changes are a standard Salesforce object. Open the App Launcher and search for Content Changes to see every change across all your stores.
The list shows each change’s Name, User (who created it), Status, Preview URL, and Published At date. Sort or filter this list by Status to find everything currently waiting on Review.
:::tip If a change was created through the Website Builder, you can also reach it from there: reopen the store in the Website Builder and select Resume on the relevant change to continue editing before you decide. :::
:::tip
If an AI agent pushed the change, its push_content_change (and get_content_change) tool responses include a salesforce_url field - a direct link straight to this record, skipping the App Launcher search above. It can be null immediately after the push, since Heroku Connect assigns the record’s Salesforce Id asynchronously when it syncs down rather than at push time - the agent’s next get_content_change call will pick up the link once sync catches up.
:::
What the statuses mean
| Status | Meaning |
|---|---|
| Draft | Still being assembled - by a person in the Website Builder, or by an AI agent mid-session. A draft hasn’t been sent to Salesforce yet, so it won’t appear in your Content Changes list at all until it’s pushed. |
| Review | Pushed to Salesforce and waiting for a decision. This is the status you’re looking for when reviewing pending work. |
| Published | Approved and applied. Setting a change’s Status to Published is the approval action - there’s no separate “Approve” button. |
You may also see an Approved option in the Status picklist. It’s a reserved value with no behavior attached yet - approving a change today means setting its Status directly to Published, not to Approved.
Inspect what a change will do
Never approve a change without reading what it contains - the Status field alone doesn’t tell you what will change on your site.
-
Open the Preview URL field on the Content Change. It links to a live preview of your storefront with every staged edit applied, so you can see the end result before anything goes live.
:::note The Preview URL only resolves once your store’s Site Base URL setting has been configured - see Test store for how to find and set it. Until then, the link won’t point anywhere useful. :::
- Scroll to the Content Change Record related list. Each row is one record being created, updated, or deleted - its Object Api Name, Action, and target record identify what’s affected (a product, a page, a menu, and so on).
- Open an individual Content Change Record to see its own Content Change Field related list. Each row shows one field’s Original Value and New Value - the precise before-and-after for that field.
For the full field-by-field reference of these three objects, see Content Change Object Reference, Content Change Record Object Reference, and Content Change Field Object Reference.
Who can approve
Approving a change requires a Store Role of type Content Changes at Approver level for the store the change belongs to.
Every Content Change also has a User field recording who created it - the person who was signed into the Website Builder, or the Salesforce user an AI agent authenticated as. Whenever that field is populated, two rules are enforced when you try to set Status to Published:
- You need the Approver role. An Editor-level role lets someone build and stage changes, but not approve them.
- You can’t approve your own change. If you’re the User recorded on the change, Salesforce blocks the save - someone else with the Approver role has to make the call, no matter whether you built the change yourself or an agent built it on your behalf.
If either check fails, Salesforce rejects the save with an error explaining why, and the change stays in Review untouched.
Editing before you approve
You’re not limited to a straight approve/reject choice. Before setting Status to Published you can:
- Edit a Content Change Field’s New Value to correct a staged value.
- Delete an individual Content Change Record to drop one part of the change while keeping the rest.
- Add a Summary noting why you made any adjustment.
Leave the Status at Review for as long as you need to inspect and adjust it - there’s no time limit.
What happens when you publish
Setting Status to Published applies every staged create, update, and delete in that Content Change to your live Salesforce records, which then sync out to the storefront.
This is all-or-nothing: if anything in the change can’t be applied - an unsupported record type, or a change record left without any fields - the whole save is rejected. Status stays at Review, and none of the change’s records or fields are applied; nothing on your site is ever left half-updated. Fix the problem (or ask whoever built the change to fix it) and try publishing again.
Was this article helpful?
Thanks for your feedback! It helps us improve our docs.