What this page is for
Approvals are on for Production. Maya is not publishing the homepage hero. She is handing Priya and Jordan a copy of it, as it is saved right now, and asking them to approve that copy. Why the copy matters is on Approvals. How the switch got turned on is Setting up approvals.
You do this in Staging or Production, on a widget or on a shared collection. You need the same group as a normal publish: Post Publish To Staging or Post Publish To Production. The Publish tab still needs View Published Resource in that environment. If the tab says Permission Required, that view group is the one you are missing. Both live under Utility Functions on the team's User Groups page.
Submit the homepage hero
- Open the hero in the environment that requires approval. Development has no Publish tab. Its tab is Integrate.
- Open Publish. If this hero has never been published here, Publishing Status offers Submit for approval where Publish Now used to be. If it is already published, the Made changes? card offers Submit for approval where Publish New Version used to be.
- The dialog title is Submit for approval to Production or Submit for approval to Staging. It asks whether to submit this widget for approval to publish it there.
- Read the two lines under the name. The first says submitting freezes this widget as it is saved now, approvers review that copy, and you can keep editing the draft, but changes you save afterwards are not part of this request. The second says that once it has enough approvals it can be published, and nothing in that environment changes until then.
- Optionally fill Note for approvers. The placeholder is "What changed, and what should approvers check?" Up to 1000 characters. Priya sees it on the request.
- Optionally open Tag this published version and add a Tag Name and Tag Description. The tag is stored on the request and, when someone publishes it, on the snapshot. Same idea as a normal publish, on Publishing.
- Click Submit for approval. The success popup offers View Request, which opens the review page.
The first time a widget would go live, the same plan check as Publish Now runs before the dialog. Submitting does not use up that allowance. Publishing the approved request does. If the team is at the limit when you later click Publish, the publish is refused and the request stays approved, so you can publish it after the plan allows another widget.
In the widget composer, the button in the top bar does the same job. It reads Submit for approval, and Submitting... while it runs. The collection composer has no publish button. Submit a collection from its own Publish tab.
The draft after you submit
Save a new headline. The composer updates. The request does not. The Approval Request card on the Publish tab is how you see that split without leaving the hero. It shows only if you are an approver for this environment or you can publish there.
- Waiting for approval · 1 of 2 approvals. Priya has approved. Jordan has not. View request opens the review. Withdraw shows for Maya, because she submitted it, and for anyone who can publish here.
- A green Approved pill, with Publish beside it, when the minimum is met. Publish is only there if you can publish. That button publishes the frozen copy. It is covered on Reviewing and publishing.
- Publishing while that publish is in progress. If the last attempt failed, the card says so and you can try again. The request is not lost.
- Rejected by Jordan, with the comment, when someone rejects. Submit for approval stays on the page. Fix the draft, then submit again. That is a new request. The rejection is closed.
A shared collection's Publish tab works the same way, without the widget plan check. The dialog adds one line: publishing it will also update any widgets that use this collection in that environment. That is the same shared-collection behavior as a normal publish.
An embedded collection still cannot be published on its own. Its Publish tab says so, the same as on Collections. It is frozen inside the parent widget's request.
One open request
The hero can have one open request per environment. Submit again while one is open — waiting, or already approved and not yet published — and the dialog warns: submitting again replaces the request already open for this widget, and its approvals do not carry over.
Priya's approval of the 20% headline does not apply to the 30% headline. She has to open the new request. The old one is closed as replaced. You can still find it under Recently closed on the requests page.
A request that is in the middle of publishing is not replaced. Wait until that publish finishes or fails, then submit if you still need a new copy.
What the request freezes
The request copies the hero and every collection it places, including a collection placed inside another collection. Layout, copy, and the CSS catalogs on those pieces are part of the copy. Media in Cloudinary is not copied into the request. The hero still points at the same image. Replacing that image in the media library changes what the preview shows, because the file changed, not because the request changed.
| What the hero uses | What approvers review | What goes live when you publish the request |
|---|---|---|
| The hero itself | The frozen copy. | That copy. Later draft edits are not included. |
| An embedded collection, including one nested inside another | The frozen copy, inside the hero. It has no request of its own. | That copy, inside the hero's snapshot. Same as a normal publish: embedded content travels with the parent. |
| A shared collection that has never been published in this environment | The frozen copy of that collection. | That copy is published with the hero, as its first snapshot. After that, the collection has its own published key. |
| A shared collection that is already live in this environment | The review shows the live version, and says this publish keeps it. The frozen copy of that collection is not what will go out. | The live version at the moment of publish. To change the collection, submit the collection itself. |
This is the sharp edge. Maya's hero places the product card. The card is already live in Production, and she has edited the card's draft since then. Submitting the hero does not submit the card. Approving the hero does not approve the card. Publishing the hero leaves the live card alone. Every other widget that uses the card stays on that same live version.
To change the card, open the card and Submit for approval there. When that request is published, every live widget that references the card updates. That is the same rule as publishing a shared collection without approvals, on Publishing. The hero dialog does not ask "Update Shared Collections." That checkbox belongs to Promote and Copy To, not to submit.
The review page says it in the product's words: shared collection "Product card" is already live in Production, so this publish keeps the live version. To change it, submit that shared collection for approval. If the card was not live when Maya submitted, and someone publishes the card before the hero, the review updates. It describes what a publish would do if you published now.
Republish is turned off
On a published version, Publish this version is how you make an older snapshot the live one again. That page is History, compare, and restore. While approvals are on for this environment, that button is disabled. The note says: approvals are on for Production. Restore this version to draft, then submit it for approval.
Restore to draft stays available. It loads that snapshot into the composer. It does not publish, and it does not submit. After you restore, open Publish and submit. Approvers then see the restored hero as a new request. The older snapshot is still in history, unchanged.
If the buttons still say Publish Now after you turned approvals on, publish anyway and the server refuses. The message says publishing to Production requires approval, so the widget was not published, and to submit it for approval instead. The page then re-reads the settings, and the button switches to Submit for approval. The reverse is the same shape: if approvals are off, submitting is refused and you are told to publish directly.
From an agent
An agent signed in as Maya can submit, because Maya can submit. It sends the same note and the same optional tag. It cannot approve as Priya unless Priya is the one signed in. Approving is that person's own decision, on Reviewing and publishing. Naming the widget or the collection is still Widgets from an agent and Collections from an agent.