Use this guide to reclaim Snapshot capacity and prevent unnecessary storage growth.
The fastest gains usually come from deleting low-value Snapshots and removing unnecessary Applications from large multi-Application Snapshots. This article focuses on those actions first, then covers a few simple habits that prevent the same problem from returning.
Before you start
A Snapshot is a read-only copy of one or more Applications at a specific moment. Snapshots can support historical comparisons, audits, reporting, or recovery after a change. Keeping duplicate or temporary copies—and including more Applications than necessary—can consume unnecessary capacity.
For more information about what Snapshots contain and how they work, see Application Snapshots.
⚠️ Before deleting Snapshot data, confirm whether anyone needs it for a historical comparison, audit, report, financial close, or to reference the model before a change. Removal is permanent.
Pigment recently moved from Application-based Snapshot limits to a Workspace-level Snapshot cell allowance.
What changed
Previously, Snapshot limits were based on the number of Applications involved, including a limit of five Applications in a single Snapshot. This was a simple measure, but it did not reflect how much data a Snapshot actually stored. A small Application and a very large Application both counted as one, even though their storage needs could be very different.
Snapshot usage is now based on the number of populated cells stored across all Snapshots in the Workspace. A Snapshot cell is one stored value at the intersection of its Dimensions—for example, one value for a particular Account, Entity, Period, and Version.
To understand where populated-cell usage is concentrated across Applications and Snapshots, see Manage Workspace Storage.
Why Pigment made the change
Application count was not a reliable measure of Snapshot usage. A Workspace with many small Applications could reach an Application-based limit while storing relatively little data, while a Workspace with fewer but much larger Applications could store considerably more.
Measuring cells ties the limit to the amount of Snapshot data actually stored.
How this benefits you
- More flexibility: a Snapshot can include more than five Applications when an end-to-end process requires them.
- Fewer workarounds: connected planning processes no longer need to be split into separate Snapshots simply because of an Application-count limit.
- Cleaner Application design: each use case can have its own Application. Teams no longer need to combine unrelated use cases into one large Application simply to stay within an Application-based Snapshot limit.
- Usage reflects actual size: small and large Applications are no longer treated as if they consume the same amount of Snapshot storage.
- Better visibility: you can review total Snapshot usage across the Workspace and see an estimated size before creating or scheduling a Snapshot.
- More control: you can focus cleanup on the Snapshots, Applications, and dependencies that consume the most cells instead of reducing the number of Applications without considering their size.
💡 What this means for cleanup: the number of Snapshots or Applications does not tell you where the biggest savings are. Start with cell consumption, then review whether the largest Snapshots and their main Applications still need to be retained.
Go to Go to Settings → Storage → Show: snapshots → Sort by Size to review Snapshot usage across your Workspace.
Prioritize by cell consumption—the amount of Snapshot storage used—rather than simply by age or number of Snapshots. One large, unnecessary Snapshot can free more capacity than many small ones.
For each of the largest Snapshots, answer two questions:
- Does the full Snapshot still need to exist?
- If it must remain, does it need every included Application?
This keeps the review focused on actions that can materially reduce usage.
Deleting an entire Snapshot is usually the strongest immediate cleanup lever.
Look for:
- Snapshots created only for testing
- Temporary copies created before a model change that has already been completed and checked
- Draft Snapshots that were replaced by a later final Snapshot
- Several Snapshots with similar names and creation times for the same event
- Automatically scheduled Snapshots that nobody uses anymore
When similar Snapshots appear to cover the same event, compare their names, owners, creation times, and included Applications. Ask the owner which copy is the final one before deleting the others.
Where possible, keep one final Snapshot for an important business event instead of every working copy created along the way.
Typical examples include an approved forecast, a quarter-end close, an annual budget, or a checkpoint before a high-risk model change. The correct retention period depends on your organization’s recovery, audit, and reporting requirements.
ℹ️ Exporting a report preserves the values shown in that report. It does not preserve a browsable copy of the Application, its formulas, its access settings, or the ability to inspect other data later. Use an export instead of a Snapshot only when the report itself is all that must be retained.
A Snapshot is useful when you need to compare historical data through the same views and structure used by the live Applications. Over time, that level of comparison may no longer be necessary. For example, you may no longer need to compare current results against 2024 through the original views, but may still need to retain selected 2024 data for reference or audit purposes.
To understand the comparison experience you would be giving up, see How to use Compare to Snapshot and Compare data with Data Slices.
Before deleting an older Snapshot, consider whether the necessary data could be kept in a simpler form. One option is a standalone archive Application that contains only the historical data that must be retained, without recreating every comparison view, formula, or dependency from the original Applications.
Because the archive exists as a standalone Application rather than a Snapshot, it does not consume Snapshot capacity. It may still use regular Workspace storage, so the design should retain only the data that is actually needed.
This article does not cover the technical setup because the right approach depends on the model, the data, and how it may need to be accessed later. Before choosing this option, answer:
- Is a like-for-like comparison through the original views still required?
- Which historical values must remain available?
- Are formulas and model structure required, or only the resulting data?
- Who needs access to the archived data, and how will they use it?
- Has the archived data been checked before the original Snapshot is deleted?
💡 The decision is not simply “keep or delete the Snapshot.” If the original comparison experience is no longer needed, retain the necessary data in a simpler form and then delete the Snapshot.
After cleanup, use a few simple rules to prevent usage from rebuilding.
Create Snapshots when you need a fixed record
Examples include:
- Budget or forecast approval
- Month-end, quarter-end, or year-end close
- Board or statutory reporting milestones
- High-risk structural model changes
Routine model iteration does not always require a permanent Snapshot. If you create a temporary pre-change Snapshot for rollback protection, delete it after the change has been validated.
Select only what the Snapshot needs
Before creating a Snapshot:
- Include only the main Applications required for its purpose.
- Include only the scenarios or Versions needed for recovery or comparison.
- Review the estimated size before creating the Snapshot.
- Review dependencies when a selected Application pulls in substantial data from elsewhere.
Remove the copy that has been replaced
When a final Snapshot supersedes a draft, temporary, or pre-change Snapshot, remove the older copy as part of completing the process. This is more reliable than relying on a separate cleanup exercise later.
If a new Snapshot remains large after you reduce the selected Applications and Versions:
- Review its dependencies.
- Identify which main Application requires each large dependency.
- Ask the relevant model owner whether that dependency is still needed.
- If it is no longer needed, clean up the live model before creating the next Snapshot.
If dependencies do not explain the size, check the live model for dense Metrics, stale Transaction List history, obsolete Versions, or temporary Blocks.
Only take this step when the potential saving justifies changes to the live model. Live-model changes affect future Snapshots only; they do not reduce storage already used by existing Snapshots.
- [ ] Open Snapshot usage and identify the largest Snapshots.
- [ ] Delete tests, retries, drafts, temporary copies, and duplicates that are no longer required.
- [ ] Decide whether older data can be retained in a simpler form before deleting its Snapshot.
- [ ] Review dependencies when the reduction is smaller than expected.
- [ ] Create future Snapshots only when you need a fixed record.
- [ ] Delete temporary or superseded copies when the related process is complete.