Changing your cluster structure between seasons is a common and supported workflow, but it has predictable side effects on in-flight plans and year-over-year (YoY) reporting. This FAQ covers what changes safely, what doesn't, and how to think about YoY comparisons across a cluster-structure change.
If you haven't already, review Automated Cluster Groups for the underlying mechanics of clusters, snapshots, and re-triggering.
FAQs
Will Changing My Clusters Affect My Current Planning Season?
It depends on what you're changing:
Creating a new Automated Cluster Group (ACG) for next season — e.g., a new
A/B/Cstructure — does not affect existing plans. Snapshotted ACGs are immutable: once a cluster group is snapshotted and tied to a plan, its structure is locked, and your in-flight plans,ROS,Weighted Planned Weeks, andAdjusted GSUall stay as they were.Editing a live (non-snapshot) ACG will recalculate location counts,
ROS, and downstream plan math on anything tied to it.Adding or moving stores — including adding a new location to an existing snapshot, or moving a store between clusters on a live ACG — will adjust plan math on the plans those clusters feed. Location counts change and forecasts re-run; you'll typically also need to run
Update Number of Locations(see the question on that below).
So for the typical "I want a different cluster structure for next season" workflow, build a new ACG, snapshot it, and your in-flight plans on the old snapshot stay exactly as they were.
Should I Edit My Existing ACG, or Create a New One?
Always create a new one when you want a different cluster structure. Editing a live (non-snapshot) ACG will recalculate location counts, ROS, and downstream plan math on anything tied to it. Creating a new ACG and snapshotting it preserves history cleanly and gives you a fresh baseline for the next season.
Will My ROS Be Accurate Under the New Cluster Structure?
Yes. Rate of Sale (ROS) is calculated from raw location-level sales history and then aggregated into clusters — not the other way around. When you build new clusters (e.g., a new A/B/C structure), the ROS for each new cluster faithfully reflects the actual sales of the locations now in it, regardless of how those locations were grouped before.
Will My YoY Reporting Still Be Apples-to-Apples?
It depends on the grain:
Reporting grain | Apples-to-apples? |
Total | Yes |
Channel / Channel Group | Yes |
Location | Yes |
Cluster (e.g., last year's | No — see next question |
Within a single season | Yes |
Cluster-level YoY across a cluster-structure change will not match, because last year's clusters and this year's clusters have different identities and different store memberships — even when some stores overlap.
What If a Store Moves From One Cluster to Another Year Over Year?
At the store level, your reporting still ties out perfectly — stores are stable and their sales history doesn't move.
At the cluster level, you'll see distortions: a store that contributed to Tier 1 last year and Cluster B this year will sit in different cluster buckets in each year. Cluster totals won't reconcile YoY for the transition period.
Can I Make Historical Sales "Follow" My New Cluster Structure?
Not through standard configuration. Historical sales data is recorded with the cluster mapping that existed at the time the plan was built. Deleting old plans, updating a default ACG, or refreshing data will not retroactively reassign historical sales to your new clusters — cluster identity is stamped at plan creation and sales ingestion.
If retroactive re-clustering is critical, that requires a one-time data migration — please reach out to your Toolio CSM to scope it.
When Does Cluster-Level YoY Become Meaningful Again?
After one full season on the new cluster structure. Once both the prior year and current year are operating under the same ACG, cluster-level YoY comparisons line up again naturally. The transition season is the only one with the mismatch.
What's the Recommended Workflow When Changing Clusters?
Build a new ACG for the upcoming season with your new cluster structure.
Snapshot it before pointing plans at it.
Leave existing snapshots untouched — they continue to support in-flight plans.
Build your new plans against the new snapshot. Location counts and
ROSwill be computed correctly at plan creation — no extra refresh step needed.Flag the transition season in your reporting so analysts know cluster-level YoY needs context.
When Do I Need to Run "Update Number of Locations"?
Only when something changes underneath an existing plan — for example:
A store's
Is Selling Locationattribute changesA store moves between clusters on a live (non-snapshot) ACG
You add or remove stores from a cluster
For a brand new plan built against a freshly snapshotted ACG, you don't need to run this — the correct location counts are populated at plan creation.
Should I Delete My Old Snapshots?
No — there's no benefit, and it can cause problems. Old snapshots are immutable and lightweight; leaving them in place preserves the audit trail of how prior plans were built and keeps closed-season plans intact.
How Should I Communicate the Change Internally?
Document the change at the boundary it occurs (e.g., "Cluster structure changed beginning FW27 — Tier 1/2/3/4 retired, A/B/C introduced"). For dashboards that show cluster-level YoY, either:
Add a note explaining the structural change,
Switch to Channel or Total grain for that comparison, or
Build a one-time crosswalk in your BI tool mapping old clusters to new for the transition year.