Skip to main content
Changing the value framework feels like the riskiest thing you can do in Minoa. It’s the library your whole team sells from, so a wrong decimal in a formula sounds like it could ripple into every live deal at once. It can’t. Two things stand between an edit and your sellers: changes stage in a private draft until you publish them, and publishing never rewrites existing business cases. That combination is what lets you restructure the framework in the middle of a quarter without holding your breath.
Editing the value framework is admin-only, whether you work in the app, with the Value Agent, or through a connected AI assistant. Sellers customize inputs inside their own business cases; the library those business cases draw from stays yours.

​
The three stages

Every change moves through the same path, no matter which tool you use to make it:
1

Draft

You edit freely in your own private staging area. Nobody else on your team sees anything.
2

Review and test

You check what changed, what each calculation now computes, and — if you want — how it behaves in a real business case.
3

Publish

You approve specific use cases by name. They become available to everyone for new business cases.
The Value Intelligence UI, the Value Agent, and any AI assistant connected over MCP all write to the same staging area. Start a change in chat and finish it in the app, or the other way round.

​
Stage 1: Draft privately

Your edits land in a personal draft the moment you make them. Drafts are per user: your colleague reviewing the framework sees the published version, not your work in progress. Find yours under Value Intelligence → Reviews, which lists every use case you have pending changes on.
A draft has no expiry, so there’s no pressure to finish in one sitting. Park a half-built use case for a week and come back to it — sellers are unaffected either way.

​
Stage 2: Review and test

This is where the real safety comes from, and it’s the stage people skip.

​
Read the computed numbers, not just the diff

A review gives you two things: a summary of what changed, and the result each calculation you touched produces on its default values. Read the second one. A misplaced decimal is glaringly obvious from “$4.2M a year for a 40-person finance team” and completely invisible in a list of edited fields. Run through this quickly:
  • Is the magnitude believable? Say the result out loud to an imaginary CFO. If you’d hedge, fix it now.
  • Is the direction right? Projected costs should land below current costs. Projected revenue above current revenue.
  • Do the defaults describe a real customer? Not the best one you ever had, and not a hypothetical.
  • Do the presets hold up? The review shows the default option’s math — sanity-check the others yourself.

​
Test a draft use case in a real business case

Reviewing the math on default values catches most problems. To see how a use case actually behaves for a seller — the input labels, the ordering, how it reads on a use case card — try it in a business case before publishing. Your unpublished use cases are available to you at the use case selection step of business case creation. Filter to Draft to find them, add one to a business case, and work through it as a seller would.
Build a throwaway business case for this. Name it something unmistakable like “ZZ Test — do not send” so nobody mistakes it for a live deal, and delete it when you’re done.
Because your drafts are private, nobody else sees the use case while you’re doing this. It’s the rehearsal most people assume they need a separate environment for.
A published use case can also be parked as hidden in the library while you keep building it out. Hidden use cases don’t appear in the listing and can’t be added to business cases at all — that’s different from an unpublished draft, which you can test with as described above.

​
Stage 3: Publish

When the numbers hold up, publish by naming the use cases you want live. There’s deliberately no publish-everything shortcut, so a half-finished draft sitting in your staging area can’t ride along with a change you meant to ship. From that point on, sellers see the updated use case the next time they build a business case.
If you staged a deletion, publishing makes it permanent. And if one of your drafts conflicts with a change a colleague published while you were working, that use case is skipped and reported back rather than overwriting their work — your draft stays put so you can re-apply it.

​
What publishing does not change

Existing business cases are untouched. A use case that’s already been added to a business case keeps the calculation, formulas, and defaults it had when it was added — permanently, unless someone deliberately updates it. This is intentional. It means you can migrate the value framework without shifting the numbers under a deal your team is mid-negotiation on, and a seller never opens a business case to find the ROI they presented last week has changed. To pull the latest version into an existing business case, remove the use case and add it back from the value framework. It comes in fresh, with every change you’ve published since — and any input values that were customized for that buyer are gone, so only do this when you mean it.
Re-adding is the only way an existing business case picks up your changes. If a formula was genuinely wrong and in-flight deals are quoting it, publishing the fix is not enough — you need to tell the owners of those business cases to re-add the use case.

​
Migrating a batch of changes

Working through a long queue of framework changes — a restructure, a new product line, a round of stale benchmarks — works the same way, just sequenced:
  1. Draft the batch. Stage as many use cases as you like; nothing is visible yet.
  2. Review in groups. Read the computed numbers for related use cases together, so you catch a benchmark you updated inconsistently across two of them.
  3. Test the ones you’re least sure about in a throwaway business case.
  4. Publish in waves. Ship the use cases you’ve confirmed and keep the rest staged. Publishing is per use case, so a batch of 25 changes doesn’t have to become one all-or-nothing event.
Have one person hold the pen. Two admins staging changes to the same use case will conflict, and the second one’s draft gets skipped at publish. Split the queue by use case, not by calculation.

​
Global inputs are the exception

Global inputs — the shared benchmarks that many use cases link to — don’t go through the draft flow. They write live, and the whole workspace sees the change immediately. They still respect the rule above: existing business cases keep the values they already have. But there’s no review step to catch a mistake, so confirm the name, data type, unit, and default before you change one. Deleting a global input unlinks it from every input that referenced it. Those inputs aren’t destroyed — they keep their current values and carry on as ordinary local inputs — but the shared benchmark connecting them is gone, and there’s no way to merge two global inputs back together afterwards. Check what exists before creating a second one.

​
Do you need a sandbox?

We can provision a separate sandbox workspace on request — reach out to support@minoa.io and tell us what you’d like replicated there. Most teams find they don’t need one. A sandbox exists to let you rehearse a change without consequences, and drafts already give you that: private edits, computed numbers before anyone sees them, a real business case to test in, per-use-case publishing, and published changes that leave in-flight deals alone. The rehearsal happens in your own workspace, on your real framework, with no data to sync back afterwards. A sandbox is worth asking for when you want something drafts genuinely don’t cover — training a group of new admins on destructive actions, for instance, or trialing a restructure so sweeping that you’d rather not have it in your live workspace at all.

​
Key takeaways

  • Nothing goes live by accident. Every change stages in your private draft until you approve it by name.
  • Publishing never rewrites existing business cases. Use cases already in a business case stay exactly as they were.
  • The flip side: fixes don’t reach in-flight deals either. Re-adding the use case is the only way to pull changes in.
  • Review the computed numbers, not the diff. A wrong magnitude shows up in the result, never in a field list.
  • You can test a draft use case in a real business case before anyone else can see it.
  • Global inputs write live. No draft, no review — confirm before you change one.