Collaborate on a Planning Model

This guide sets up a review workflow for a planning model without giving every participant full model control.

Before You Start

Assign:

• one accountable model owner
• the teammates who can edit
• the teammates who can propose changes
• the reviewers who need comment access
• the viewers who only need results

Agree on the decision date and the output under review.

1. Save the Starting Point

Create a named version before collaborative review begins.

Use a label such as FY27 plan before department review.

This version separates the starting state from changes made during review.

2. Prepare a Review Scenario

Create or select a scenario for the proposed case.

Use a specific label and keep unrelated edits out of the scenario. The scenario should make the proposed assumptions easy to identify.

3. Add Comments to the Relevant Rows

Open Comments.

For each question:

1. Select the affected row.
2. State the assumption or issue.
3. Name the owner or evidence needed.
4. Reply in the same thread.
5. Resolve the thread after the decision is recorded.

Keep model-specific rationale in the model instead of splitting it across private messages.

4. Save a Focused View

Include:

• the assumptions being reviewed
• the resulting outputs
• the required periods
• the active scenario
• rows with open comments

Give the view a label that identifies the audience and case.

5. Share the Correct Access

The model owner selects:

Do not grant edit access only to let someone leave feedback.

Before sharing, check whether visible totals include hidden child rows. Also use variable filters when a row must be hidden because a scenario filter alone still shows base-backed variables.

6. Create a Change Proposal

When proposal controls are available, switch to a non-base scenario with changes and select Propose “Scenario” changes.

The proposal captures eligible ordinary variable-and-period overrides. Dimension-specific scenario overrides are not included in the current proposal action.

Give the proposal enough context for the reviewer to understand the intended base change.

7. Review the Diff

A reviewer should check:

• each changed variable
• each affected period
• the source scenario
• key output changes
• current actuals and model revision
• comments related to the change

Reject the proposal when the assumptions or model context need revision. Approve it when the change is acceptable. Merge applies the approved change set.

8. Protect High-Impact Operations

Only the appropriate owner should:

• promote a scenario to the base
• merge scenario overrides into the base
• restore a version
• change the model timeline
• manage saved-view shares

Tell active collaborators before one of these operations.

9. Close the Review

After the decision:

1. Merge or reject the proposal.
2. Resolve completed comment threads.
3. Save a named version of the approved state.
4. Update the saved view.
5. Export a point-in-time copy when required.
6. Remove access that is no longer needed.

Troubleshoot

A reviewer cannot comment

Confirm the saved view is shared as Can comment or Can edit.

The proposal button asks for scenario changes

Switch from the base to a scenario with eligible overrides.

A proposal misses a dimension-specific change

Document and review that change separately. The current proposal action excludes dimension-coordinate overrides.

The proposal diff is stale

Refresh the model and compare the proposal's base revision with the current model. Recreate the proposal when necessary.

A participant can preview but cannot restore a version

That is expected for scoped or read-only access. Restore is a model-wide operation.

Next Steps

• Planning Versions and Collaboration
• Planning Views and Exports
• Review, Restore, and Export a Planning Model