Review and approve content changes

Edits made in the Website Builder, and edits an AI agent pushes through connected agent tools, are staged as content changes. A staged change does not reach your live site until a person with an approver role reviews and publishes it.

Only those two routes are staged. Editing a record directly in Salesforce, such as a Page or Content Block, has no review step: the edit goes live as soon as Salesforce syncs it to your store.

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, assigned to you with a Store Scope that covers the change’s Origin Store. Changes made in the Website Builder have no Origin Store, so publishing them needs Store Scope set to All. 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. To check the change on another store, or to share the preview with a reviewer, see preview and stage theme changes.

   :::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 change’s Origin Store, the save is refused with You need an approver-level Store User Role for content changes to publish this change. A change made in the Website Builder has no Origin Store, so only a role with Store Scope set to All covers it.
• 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.

Publish Own Changes does not wait for someone else to approve the change first. Approving has no author check, and a content change does not record who approved it, so someone with the scope can approve and publish their own change with no second person involved. To keep two people on every change, leave the scope off the author’s role and have the reviewer publish the change after approving it.

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, none of it is applied, so your site is never left half-updated. How that is reported depends on when the problem is found.

Problems found before anything is applied

The save is refused outright, naming the record at fault, and the change stays where it was. This covers:

• 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.

Fix the record, or ask whoever submitted the change to fix it, and publish again.

Problems found while applying

Some problems only surface when the staged records are written, such as a staged identifier that now matches one already live, or a lookup to a record that has since been deleted. StoreConnect rolls back whatever had been applied, returns the change to draft, and records why on the change’s Publish Error field. The reason names the staged object type that was being applied and the error Salesforce reported, for example:

Publish failed and no part of this change was applied. While applying the create of s_c__content_block__c: Insert failed. First exception on row 0; first error: DUPLICATE_VALUE, duplicate value found: s_c__Identifier__c duplicates value on record with id: a12...

Because the change is a draft again it leaves the Console queue, which has no Draft tab. Open it under Content Management > Content changes > All content changes to read Publish Error.

:::note A package upgrade does not change your page layouts. If your org installed StoreConnect before Publish Error existed, add the field to your Content Change page layout to see it on the record. :::

From there you can:

• Fix the cause and publish again. The change is back with whoever made it: in the Website Builder it is their pending change again, and an agent’s change is a draft it can revise. Correct the staged value, or the live record it collided with, then submit, approve, and publish once more. A publish that succeeds clears Publish Error.
• Discard it. A draft can be discarded, which a change stuck in review could not be. An agent discards its own change with discard_content_change.

When you publish from the Console, the panel reads the result back: a publish that did not apply shows a was not published message carrying the reason, and the queue refreshes without moving to the Published tab. Publishing from the Salesforce record gives no such message, because the save itself succeeds; if a change you published from the record is not on your site, check its Status: draft with a Publish Error means nothing was applied.

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.