Workflows
Staging and publishing
Publishing should begin with a concrete before-and-after proposal. A staged deployment makes the intended store changes inspectable before they are submitted.
Updated
A draft is a bounded change set
The draft groups selected recommendations into one reviewable action. It identifies the affected app, products, plans, markets, existing prices, and proposed prices so the scope is clear.
This is the point to remove unintended markets and check relationships across the catalogue.
Validate against the current store
A draft is based on a particular store state. If that state changes before publication, the proposal needs to be checked again rather than overwriting newer work with an older assumption.
This makes staleness visible and turns it into a new review decision.
Publish, read back, and retain context
After an approved submission, the result should be checked against the provider and recorded at item level. A partial outcome is different from a complete one and should be presented that way.
Rollback access uses the recorded deployment context to prepare a reversal. The dashboard contains the exact controls and current availability because those details belong beside the live account state.