Scenario

Scenarios let you branch a model into named versions so you can try changes safely, compare outcomes, and merge approved changes back into Main Scenario.

Use Scenarios when you need:

• Safe experimentation without changing the live model
• A locked baseline (budget, board plan, approved forecast)
• A review workflow (draft → review → merge)

Key concepts

• Main Scenario: the default “live” branch. It is always available and cannot be deleted.
• Scenario: a branch derived from Main (or duplicated from another scenario).
• Overrides: scenario-specific changes that differ from the inherited baseline.
• Inheritance / auto-sync: when enabled, non-overridden values continue to follow Main Scenario.
• Merge: directional operation that applies only overrides from a source scenario into a destination scenario.

Common tasks

1) Create a new scenario

1. Open the Scenario switcher (top bar).
2. Select New Scenario.
3. Give it a clear name (example: “FY26 Base – Draft” or “Headcount Cut – Alt”).
4. You’ll land in the new scenario.

Tips:

• Use naming that encodes purpose and lifecycle (Draft/Review/Locked).
• Avoid duplicates; if you need iterations, add a suffix (v2, Apr, etc.).

2) Switch scenarios

1. Open the Scenario switcher.
2. Pick a scenario from the list.

Expected behavior:

• The active scenario should be visible at all times.
• Your editing context follows the active scenario.

3) Make changes safely

When you edit in a non-main scenario, changes should remain isolated to that scenario until you merge.

If you’re unsure where you are:

• Check the active scenario label before editing.
• If the product shows visual cues (badges/colors), treat them as authoritative.

4) Compare scenarios

Use Compare to review how a scenario differs from Main (or another baseline).

Use cases:

• “What changed vs Main?”
• “What’s the variance vs our locked budget scenario?”

5) Duplicate a scenario

Duplicate creates a new scenario using the current effective state of an existing scenario.

Use this when:

• You want to continue planning from an approved baseline.
• You want a new branch without disturbing the existing one.

Expected behavior:

• The duplicate should include the source’s effective values.
• Identity fields (created by/time) are new for the duplicate.

6) Merge changes

Merge moves overrides from a source scenario into a destination scenario (often Main).

Steps:

1. In the source scenario, choose Merge Changes.
2. Select the destination scenario.
3. Confirm the merge.

Expected behavior:

• Merge is directional.
• You cannot merge a scenario into itself.
• Only overrides are merged (not a full snapshot).
• A merge should create an audit/history event.

Scenario settings (how to interpret them)

Auto-sync from main

• ON: your scenario keeps inheriting changes from Main, except where you’ve made overrides.
• OFF: your scenario stops receiving new Main changes; it becomes more “frozen.”

Good defaults:

• Exploratory scenarios: Auto-sync ON
• Baselines/approvals: Auto-sync OFF

Allow Changes (Editability)

• ON: permitted users can edit the scenario.
• OFF: scenario is read-only (locked).

Enforcement expectations:

• UI edits should be blocked when OFF.
• API/import/job/agent writes should also be blocked.

Allow Merging (Mergeability)

• ON: scenario can be used in merge flows per permissions.
• OFF: merge should be disabled.

Note: Some products interpret this as “can be a merge source.” If that’s the case, it controls merging from this scenario, not necessarily merging into it.

Who can view (Visibility)

• All Members: visible to everyone in the workspace.
• Only Admins: restricted visibility.

Expected behavior:

• Restricted scenarios should not appear in the switcher for unauthorized users.
• Direct links must still enforce permissions.

Rules of thumb

• Treat Main Scenario as the safe, default “truth” branch.
• Use a dedicated scenario for risky experiments.
• Lock scenarios that represent approved states.
• Merge intentionally, and prefer merging small, understood override sets.