Every planning platform does scenarios. The difference is what a scenario is underneath, and there are only two answers.
On most platforms a scenario is a version flag inside a shared dimensional structure. It shares a data space with every other scenario, which means each one you save adds weight to the model and scenarios contend with each other rather than running in parallel.
On a smaller number of platforms a scenario is an isolated computational space with its own memory and logic. Saving one costs the others nothing, and they run simultaneously.
That single design decision determines how many scenarios you can hold, whether they can differ structurally or only in their data, and whether your team asks every question worth asking or quietly learns to ration. If you are evaluating for scenario modeling, ask which of the two you are buying and stop evaluating features until you have the answer.
Teams rarely say their platform limits scenario planning. They say they do not have time to run more scenarios.
Those are usually the same statement. When a scenario takes a day to build and a rebuild to modify, people stop asking marginal questions. The board asks what happens if we delay the European launch two quarters and the honest answer is we can model that for the next meeting.
This is the most expensive constraint in planning because it is invisible. There is no error, no ticket, no line item. There is just a smaller set of questions being asked, and nobody counts the questions they did not ask.
Worth being precise about, because the two look identical in a demo.
Scenario as a version flag. The platform holds one dimensional structure and adds a version dimension to it. A scenario is a set of values tagged to a version. Straightforward, and it works well for a handful.
Two consequences follow. Each saved scenario contributes to model size, so performance degrades as you accumulate them, and you will eventually be advised to archive old ones. And scenarios share a calculation space, so they can contend with each other, which is why scenario processing on these platforms is often sequential rather than parallel.
There is a third consequence that bites harder than either. If scenarios are values against a shared structure, then scenarios cannot differ structurally. You can change assumptions. You cannot easily model a reorganisation that adds a dimension, a new business unit with a different hierarchy, or an acquisition whose chart of accounts does not match yours. Those are exactly the scenarios worth modelling.
Scenario as an isolated space. Each version has independent memory and logic. Saving one has no effect on the others, several run at once without contention, and a version can carry its own business logic rather than only its own numbers.
The test question is simple and unambiguous: show me two versions of this model that differ in structure, not just in data. Platforms in the first category cannot do it.
What happens to performance after forty saved scenarios? Not four. The number you will actually accumulate over two years of quarterly planning, reforecasts and board requests. Ask whether anyone has to archive them, and why.
Can two versions differ in structure, not just in data? Ask for a live demonstration rather than a yes.
Can several scenarios run at the same time? And can several people work in different scenarios simultaneously without locking each other out? During a planning cycle this is the difference between parallel work and a queue.
How do you compare scenarios that were not built the same way? Comparison across structurally different versions is where most platforms fall over, and it is exactly what you need when comparing a base plan against an acquisition case.
Three or five named scenarios is a coarse instrument for a genuinely uncertain input. Best, base and worst case are three points on a distribution, chosen by whoever built them, and the spacing between them usually reflects temperament rather than probability.
Probabilistic simulation is the alternative: run the model many times with inputs varying across plausible ranges, and read the distribution of outcomes rather than three points on it. It tells you which assumptions actually drive variance, which is frequently not the ones the debate is about. Worth being clear that this is classical statistical simulation rather than anything to do with AI, whatever it gets bundled under.
It remains uncommon in enterprise planning platforms. Where it is absent, teams export to a separate tool, which usually means it happens once a year rather than as part of planning.
Fintastic. Versions are isolated execution environments with independent memory and logic. Saved scenarios do not degrade the performance of the others, workflows run in parallel without user lockouts, and versions can be compared across different structures rather than needing to match. Monte Carlo simulation runs against existing plans, with control over participating entities and noise levels.
Anaplan. Capable multi-dimensional scenario modelling with a mature ecosystem. Versions can differ in the data they hold but not in dimensions, hierarchies or formulas, and scenarios contribute to model size, so the practical number is bounded.
Pigment. Good interface and quick to adopt. Each version adds weight to the model, and comparing two scenarios requires them to have been built the same way, so structurally different cases are the constraint to test.
Workday Adaptive. Built-in scenario planning that works within its GL-centric design. Scenario performance degrades with dimensionality, and versions rely on a single global model with fixed dimensions and global formulas.
Cube, Vena, Drivetrain. Serviceable for a small number of scenarios at moderate dimensionality. The ceiling arrives sooner than teams expect.
Not a scenario list. Bring the three questions your board asked last year that you could not answer in the meeting.
Ask each vendor to model them live, at your real dimensionality, while you watch. Then ask them to save all three and model a fourth, and watch whether anything slows down.
That exercise tells you more than any feature matrix, because it tests the thing you are actually buying: whether your team will ask the next question or decide it is not worth the rebuild.
Scenario isolation is an architectural property here rather than a feature. Each version is a separate execution environment, so scenario count is a question of what is useful rather than what the model can carry, and versions can be compared even when they were not built identically.
That matters most for the cases that are hardest to model elsewhere: an acquisition with a different chart of accounts, a reorganisation that changes the shape of the business, a new market that adds a dimension. Those are not assumption changes, and platforms that treat scenarios as values struggle to represent them without a rebuild.
Priceline moved scenario analysis from five interconnected models to one and from 15 minutes per calculation to 13 seconds, with more than twenty concurrent users where two to five had previously caused model freezes, and ran more than forty sensitivity scenarios in their first budget cycle. The speed is the visible change. The one that altered how they work is that scenarios stopped being scheduled.
The honest boundary: if you run three scenarios a year and they differ only in growth rate, any platform on this list will do, and this is not where your budget should go.
Almost always the architecture rather than the team. On platforms where a scenario is a version flag inside a shared dimensional structure, each saved scenario adds weight to the model, so performance degrades as they accumulate. On platforms where each version is an isolated computational space, saving one costs the others nothing.
On some platforms only. If scenarios are values tagged to a shared structure, you can change assumptions but not dimensions, hierarchies or formulas. That rules out modelling an acquisition with a different chart of accounts or a reorganisation that changes the shape of the business, which are the scenarios most worth running.
Because the scenarios share a calculation space. When they are not architecturally independent they create contention, so the system cannot hold several live at once. Platforms that isolate scenarios into separate computational spaces run them in parallel by design.
It runs the model many times with inputs varying across plausible ranges and returns a distribution of outcomes rather than three named cases. It is classical statistical simulation rather than AI, and it is most useful for identifying which assumptions actually drive variance. It remains uncommon in planning platforms, so teams that want it often export to a separate tool.
Bring the three questions your board asked last year that you could not answer in the meeting. Ask each vendor to model them live at your real dimensionality, then save all three and model a fourth while you watch for slowdown. That tests what you are actually buying.
Ask about forty rather than four, since that is roughly what accumulates over two years of quarterly planning, reforecasts and board requests. If the vendor's answer involves archiving old versions to maintain performance, scenarios are contributing to model size and there is a practical ceiling.
