Review and approve content changes

Every edit to your storefront is staged first as a content change, whether a person made it in the Website Builder or an AI agent pushed it through connected agent tools. Nothing reaches your live site until a human reviews that change and publishes it.

Use this process to find changes waiting on you, see exactly what each one will do, and publish or send it back.

Two places to do this

Both routes act on the same records, and a change moves through the same states either way. Pick the one that suits the job.

• The Content changes queue in the StoreConnect Console. A purpose-built review screen: changes grouped by state, a summary of what each one touches, a field-level diff, and a storefront preview. Use this for day-to-day review.
• The content change records in Salesforce. The underlying records as ordinary Salesforce data, with list views, reports, and inline editing. Use this to correct a staged value, drop part of a change, or send one back, none of which the Console queue does.

How a change reaches you

A change starts as a draft. Drafts stay on the website side and never reach Salesforce, so a change you cannot see yet is one nobody has submitted. Submitting it sets its status to review, which is when it appears in both places above.

An agent submits by calling push_content_change. StoreConnect checks the staged content at that moment and returns any warnings to the agent, so some problems are caught before the change ever reaches you. A content block whose custom template resolves nowhere is rejected outright and never becomes your problem. Every other warning is advisory: your approval is still the gate.

What the states mean

Console tab	Stored status	Meaning
Needs approval	review	Submitted and waiting for a decision.
Ready to publish	approved	Approved, but not yet applied to your live content.
Published	published	Applied. This is history, and there is nothing further to do.

There is no Draft tab, because a draft never reaches Salesforce.

Approving and publishing are deliberately separate. Approving is cheap and reversible, and touches nothing on your storefront, so you can approve in bulk. Publishing writes the staged records to your live content and cannot be undone from the Console, so it is one change at a time.

Before you begin

You need to set up the following roles and permissions.

• A Store Role of type Content Changes at Approver level, covering the store the change belongs to. A role scoped to that store, to its store group, or to all stores all satisfy this. See Store roles.
• The StoreConnect Content Change Approver permission set, which grants the review screens, read access to the content a change can touch, and edit on the Status field. The permission set alone does not let anyone publish; the store role is also required.

Review and publish via the Console

1. Open the StoreConnect Console and go to Content Management > Content changes > Manage content changes.
2. Select the Needs approval tab. Each tab carries a count of what it holds. Use Search changes to filter by name or summary, and the sort control to switch between newest and oldest first. Oldest first is what drains a backlog.
3. Select a change. The panel on the right shows its name, the summary whoever submitted it wrote, who submitted it, and when it arrived.
4. Read the composition list in that panel. Each row is an object type the change touches and how many records of it are staged, for example Pages 1. Select a row to open the record explorer.

5. In the explorer, check what each staged record does. Every row carries a create, update, or delete chip, and the filters above narrow the list to one action. Open a row to see the field-level diff: each field’s original value beside its new value, labeled with both its name and its API name.

   :::warning Check the deletes before anything else. A deletion renders as nothing at all on the storefront preview, so the explorer is the only place you can see what a change removes. :::

6. Select Preview on storefront to see your site with the staged edits applied. This is a live preview of the end result, and it opens in a new tab.

   :::note The preview link only resolves once your store’s Site Base URL is set. See Test store for where to find it. :::

7. Select Approve. The change moves to Ready to publish.

   To approve several at once, select the checkboxes on the rows you want, or the select-all checkbox above them, and approve the selection. Bulk approval is offered on Needs approval only.

8. Open the Ready to publish tab, select the change, and select Publish. Confirm when asked.

The change moves to the Published tab with a Published timestamp, and the staged records are applied to your live content, which then syncs out to the storefront. Load the affected page on your site to confirm the edit is live.

Review changes directly in Salesforce records

Use this route to change what a content change contains, or to send it back. Go to Content Management > Content changes > All content changes for the full list, or Content change records for the individual staged records across every change.

A content change holds Content Change Records (s_c__Content_Change_Record__c), one per record being created, updated, or deleted. Each of those holds Content Change Fields (s_c__Content_Change_Field__c), one per field, with its Original Value and New Value. For the full field lists, see the Content Change, Content Change Record, and Content Change Field object references.

From here you can:

• Edit a Content Change Field’s New Value to correct a staged value.
• Delete a Content Change Record to drop one part of a change while keeping the rest.
• Set Status back to Review to return an approved change for more work, or note in Summary why you adjusted it.
• Set Status directly to Approved or Published, which does the same thing as the Console buttons.

There is no time limit. A change can sit at Review for as long as you need.

:::note The Console queue has no reject button. To send a change back, either set its Status here, or ask whoever submitted it to revise it. An agent discards its own change with discard_content_change. :::

Who can publish site changes

Two checks run whenever a change moves to published, and both are enforced in Salesforce, so they apply on either route.

• You need the approver-level role. An Editor role lets someone build and submit changes, not publish them. If your role does not cover the store the change belongs to, the save is refused with You need an approver-level Store User Role for content changes to publish this change.
• You cannot publish your own change by default. Every content change records the user who created it, which for an agent is the Salesforce user it signed in as. If that is you, the save is refused with You cannot publish a content change you authored yourself. Ask another approver to review and publish it, or your administrator can add the Publish Own Changes scope to your role.

The second check is a default, not an absolute. A Content Changes role whose API Scopes include Publish Own Changes lets its holder publish changes they authored, which is what a solo operator running their own agent needs. No role carries it out of the box, and the approver-level check still applies to a self-publisher exactly as it does to anyone else. See Store roles.

When either check fails the change stays where it was, untouched.

What publishing does on your site

Publishing applies every staged create, update, and delete in that content change to your live Salesforce records, and stamps Published At.

It is all-or-nothing. If any part cannot be applied, the whole publish process is refused and none of it is applied, so your site is never left half-updated. Two cases are worth knowing, because both result in no changes being published, naming the record at fault.

When you see a message relating to the following, you need to fix the problem, or ask whoever submitted the change to fix it, and publish again.

• A content change with no Content Change Records on it at all.
• A Content Change Record other than a delete that has no Content Change Fields.

Example publishing workflow

An agent updates the subtitle on your Restaurant page and calls push_content_change. The change appears on Needs approval with the summary the agent wrote and a composition of Pages 1. You open the explorer, see one update row, and read the diff: Subtitle changes from Lunch among the vines, Thursday to Monday to Long lunches among the vines, Thursday to Monday. The storefront preview shows the new subtitle in place. You approve, then publish from Ready to publish, and the page on your live site carries the new subtitle.