Scenarios

Scenarios let you explore possible changes to an ownership diagram without changing the base diagram. You can create a scenario, add steps, adjust the structure and layout, and return later without losing the scenario's own working state.

Key Idea

A scenario starts from the base diagram, but it does not stay tied to the base diagram's layout forever.

• The base diagram seeds the scenario when the scenario is first created.
• Each new scenario step starts from the previous scenario step.
• Existing scenario steps keep their own geometry, settings, and scenario changes.
• The base diagram's entity filter still controls which base entities are in scope.

Creating a Scenario

When you create a new scenario from a base diagram, StructureGram creates the first scenario step.

At that moment, the first step receives a snapshot of the base diagram's current canvas state, including:

• Entity positions
• Link vertices and routing
• Manual layout state
• Flex routing state, if flex routing is active
• Diagram presentation and view settings

This copy happens once. After the scenario is created, edits to the base diagram's layout do not overwrite the scenario's first step.

Revisiting an Existing Scenario

When you reopen an existing scenario or scenario step, StructureGram loads that step's own saved state.

This means the step keeps its own:

• Scenario entity and relationship changes
• Entity positions
• Link vertices
• Layout mode and routing settings
• View and presentation settings

Revisiting a scenario does not take a fresh layout copy from the base diagram.

Creating a New Step

When you create a new step inside an existing scenario chain, the new step starts from the scenario step you are currently working from.

The new step carries forward the prior step's scenario-local canvas state, including:

• Manual entity positions
• Manual or flex link vertices
• Layout engine and routing settings
• View and presentation settings

After the new step is created, it has its own life. Later changes to the previous step do not automatically rewrite the new step.

Revisiting an Existing Step

Existing steps are not rebuilt from base or from earlier steps each time you open them.

When you open a step, StructureGram resolves the scenario changes up to that step and then applies the step's own saved canvas state. This keeps earlier planning work stable while still letting you move between steps.

How Entity Filters Affect Scenarios

Entity filters behave differently from layout and geometry.

The base diagram's active entity filter controls the base scope used by the scenario. If you change the entity filter on the base diagram, that scope change is reflected when scenarios are resolved.

In ownership diagrams, applying Focus Entity in the Entities dialog is one way to make that base scope change quickly.

This means:

• If a base entity is removed from the active entity filter, it may disappear from the scenario view.
• If a base entity is added to the active entity filter, it may become available in the scenario view.
• Scenario-specific changes still apply on top of the filtered base data.
• Scenario step layout is not reset just because the entity filter changes.

See Focus Entity (Ownership Diagrams) for the exact behavior of that apply action.

Think of the entity filter as the current base data boundary. Think of scenario steps as their own planning layers inside that boundary.

If you create a new entity after the base diagram was created, add it to the base diagram's entity filter before expecting it to appear in scenarios based on that diagram.

Auto Layout, Manual Layout, and Flex Routing

Scenarios preserve the layout state they are created with.

If the base diagram is in manual layout, the first scenario step starts with the same manual geometry. If the base diagram uses flex routing, the first scenario step starts with the same flex routing settings and carried-forward vertices.

For later steps, the same rule applies from step to step: the new step starts from the current scenario step's layout and routing state.

Practical Example

1. You open a base ownership diagram with 10 entities in its entity filter.
2. You arrange the diagram manually and use flex routing.
3. You create a scenario.
4. Step 1 starts with the same entity positions, flex routing settings, and link vertices.
5. You move entities and change relationships inside Step 1.
6. You create Step 2.
7. Step 2 starts from Step 1's current scenario state.
8. You later change the base diagram's entity filter from 10 entities to 9.
9. The scenario resolves against the new 9-entity base scope, but each existing step keeps its own saved layout state as far as possible.

Committing Changes

A scenario change stays in the scenario until you commit it. Committing saves that change to your live data, exactly as if you had made the same edit, creation or deletion outside the scenario. The same checks apply, so a change the live data won't accept is refused with a message.

To commit a change:

1. Open the scenario step where you made the change.
2. Select the changed entity or relationship to open it in the inspector.
3. Under Scenario Actions, click the commit button. Its label matches the change:
   • Commit Creation for something the step added;
   • Commit Changes for something the step edited;
   • Commit Deletion for something the step removed.
4. Confirm in the dialog that opens.

You commit one change at a time. Changes you don't commit stay in the scenario.

Reviewing an edit

For an edit, the Review changes to commit dialog lists each field the scenario changed, with its Live value and its Proposed value.

• Tick the changes to save to the live record. Unticked changes stay in the scenario.
• Click Commit changes to save them all, or Commit N of M when you've ticked only some.
• Click Cancel to close without saving. The changes stay in the scenario.

If the dialog says the change "commits together with" related changes, those related changes are saved with it.

Creations and deletions

For a creation or deletion, a confirmation dialog (Commit New Creation or Commit Deletion) tells you what will be created or deleted, and lists anything that commits with it. Click Create or Delete to confirm. A committed deletion can't be undone.

Changes made in earlier steps

An entity created in an earlier step is committed from that step. In a later step its inspector says: "Created in an earlier step. Commit it from that step."

If a commit is refused because it relies on an earlier step, the message adds: "Earlier steps have uncommitted changes; committing them first may resolve this." Commit the earlier step's changes first, then try again.

Summary