# Promote a scenario

Source: https://docs.tightly.io/help/commitments/act-promote-a-scenario
Reviewed: 2026-09-26

## What it writes

Promote a scenario backs a recorded scenario and records the prediction it is backed on. Two paths: a diff that only moves depths and prices inside the envelope lands promoted, the buy that is being made; a diff that moves or newly declares the envelope, or whose buy costs more than it, lands pending approval, because the envelope is the number the commitment was approved on, so changing it is an amendment and this asks rather than arms. It also lands pending approval when the commitment declares an envelope and the money already placed on it cannot be stated because an order line has no unit cost: the buy cannot then be checked against the envelope, so it asks whatever the buy reads. A change to demand assumptions alone has no buy to check, so this does not apply to it. It lands pending approval too when the commitment declares an envelope, a demand shock raises demand in a sales channel, and a style's forecast cannot be split by channel in full, because what the rise adds to the buy cannot then be stated. Only a promotion that takes the promoted slot supersedes: the scenario that was promoted before on the same commitment becomes declined and is kept, with its diff and its recorded prediction, because it is the counterfactual this promotion will be scored against. One that goes to approval supersedes nothing, and the running scenario keeps the buy until somebody signs. Backing records a decision only: it applies no worked depths and submits no declaration.

## Who may press it

An admin, on a plan that includes Commitments. The act's home is the scenario row on [Work the buy](../commitments/the-desk): press Review decision, add a decision note if you want one, and press the backing button, which reads Choose this scenario inside the envelope and Record approval required across it. The prediction comes from what the working copy sums to; nobody types it. Ask Tightly may propose it as `promote_commitment_scenario`; pressing the chip asks Ask Tightly to restate the act, your yes is the confirm, and the route checks your own seat, so a seat below admin is refused there. Over MCP nothing here writes; the act stays a person's press.

## What you see

The hover says which path it takes; the receipt under the row names the outcome:

> “{name}” is recorded as the chosen scenario.

> “{name}” is recorded as requiring approval.

Where it went to approval for a missing unit cost, the promotion records why:

> The money already placed on this commitment cannot be stated, because an order line has no unit cost, so this buy cannot be checked against the envelope and goes for approval. Set a cost on that order line to check it.

Where a channel shock went to approval because a style's forecast could not be split by channel, it records, for one style:

> This change raises demand in a sales channel, and one style's forecast cannot be split by channel in full (the split could not be read, or part of it is on a channel whose type is not known), so what it adds to the buy cannot be stated and it goes for approval.

In [Scenarios](../commitments/scenarios) the row then reads Chosen decision or Awaiting approval, and a superseded scenario reads Not taken.

## What to do

The way back is to promote another scenario (declining this one and keeping it), or to [Decline a scenario](../commitments/act-decline-a-scenario) with a reason. A promotion is never removed from the ledger. An unrecorded view is saved first with [Record a scenario](../commitments/act-record-a-scenario).

## Refusals you may read

Before the press, the button stays closed and its hover says why:

> This has changes that are not on the ledger yet. Record it first — a promotion is a claim about a scenario that exists, and there is nothing yet to make the claim about.

> Nothing has been recorded yet, so there is no scenario to promote. Record this working copy first.

> This scenario has already been decided. Record a new one rather than backing this one twice.

A scenario the working copy cannot carry whole reads its own reason in place of Record and Promote, with a door to the wall:

> This scenario has what-ifs this page does not show. Open it on the Scenarios wall to change or promote it.

While the server is still pricing the diff, Promote reads its own status rather than the working copy's:

> The server is pricing this scenario. It can be chosen once the server has priced it.

On the server, a scenario that is not a draft is refused by name and state: a promoted or pending one has already been backed, and a declined one is the record of a decision. A buy that cannot be priced while the commitment declares an envelope is refused before anything is written, unless the money already placed on it cannot be stated, which goes to approval as above:

> This buy could not be priced, so it cannot be checked against the envelope. Price it, then promote.

A scenario backed concurrently by someone else asks you to refresh and retry. Where two promotions race for one slot, the second is refused, naming the scenario already promoted, and ends:

> Only one scenario at a time may be the buy that is being made.

A discount scenario is refused here, sent to its markdown approval instead.