Versioning

Change rules with confidence, not crossed fingers

Business rules versioning that makes change feel safe. Work on a draft, test it with real examples, publish when you are ready, and keep every earlier version in case you need it.

See your decision running How it works

Incoming request

evaluating

What changed in the approval rules since last month?

Create a draft of the PO approval decision and update the limit.
Run it with three real POs: 4,800 GBP, 6,200 GBP and 9,000 GBP.
Check the trace: the 6,200 GBP PO now goes to the manager, the 9,000 GBP PO still goes to the director.
Publish on the first day of the quarter.

Answer, with the reason

The new limit is live from the moment it is published, tested against real examples first. The old version is kept as Inactive, and run history shows which version answered every PO before and after the change.

Sound familiar?

Changing a live rule should not feel like defusing a bomb

The rule needs to change. Everyone knows it. Nobody wants to be the one who changes it, because nobody is sure what else will break.

Edits made straight into live

Someone updates the limit in the spreadsheet or the config table. It takes effect immediately, for every order, whether it was right or not.

No way back

When the change turns out to be wrong, nobody remembers the old value. The fix is another rushed change.

No record of what applied when

A customer disputes a decision from March. The rule has changed twice since. Which one decided their case?

The quiet cost

What fear of change quietly costs

Rules stay out of date because changing them feels risky.
Changes pile up and go live together, so problems are harder to trace.
A mistake in live takes longer to undo than it took to make.

Before and after

From crossed fingers to controlled change

Today

Changes are made directly to the rule that is running.
Testing happens after the change is live.
Old versions are lost once they are overwritten.
Nobody can say which rule applied to a past decision.

With Condexa

Changes are made on a Draft version while the Active one keeps running.
You test the draft with example values and read the trace first.
Earlier versions are kept, marked Inactive, ready to look back on.
Run history shows every past decision with its inputs, outputs and trace.

How you get there

How versioning works in Condexa

1
Draft without risk
Create a new Draft version and make your changes. Your systems keep calling the Active version, untouched, until you are ready.
2
Test, then publish
Run the draft with real examples and check every answer in the trace. When it is right, publish it and it becomes the Active version your systems call.
3
Keep the history
The previous version is kept as Inactive, and every call is kept in run history. If you need to stop a decision entirely, switch it off.

A worked example

Worked example: raising an approval limit safely

Finance wants to raise the department manager's PO approval limit from 5,000 GBP to 7,500 GBP from the start of the new quarter.

The rules, in plain English

R1Create a draft of the PO approval decision and update the limit.
R2Run it with three real POs: 4,800 GBP, 6,200 GBP and 9,000 GBP.
R3Check the trace: the 6,200 GBP PO now goes to the manager, the 9,000 GBP PO still goes to the director.
R4Publish on the first day of the quarter.

Condexa answers

FAQ

Questions people ask

What is business rules versioning?

Business rules versioning means every change to a rule creates a new version rather than overwriting the old one. You can work on a new version without affecting the one in use, publish it when ready, and see which version applied to any past decision.

How do I roll back a business rule change?

In Condexa, earlier versions are kept when you publish a new one. If a change turns out to be wrong, you can go back to the previous logic rather than trying to remember what it was, and run history shows every decision the changed version made.

What is rule change control?

Rule change control is the process around changing business rules: who can make a change, how it is tested and who approves it going live. Condexa supports it with Draft and Active versions, testing with a trace, and workspace roles that separate authors from publishers.

Can we test a new version without affecting live systems?

Yes. Draft versions can be run with your own example values in Condexa. Your systems only ever call the Active version, so nothing changes for them until you publish.

What is run history?

Run history is the record of every call made to a decision, with its inputs, outputs and trace. It lets you answer 'why did the system say that?' for any past decision, even after the rule has changed.

Keep exploring

Related decisions and guides

Problems

Rule changes need developers

Waiting weeks for IT to change one threshold? Let the people who own the policy change it themselves, safely.

Features

Decision trace

Someone asks why the system said no. Open the run and show them every step, every value and the rule that decided.

Features

Workspaces

Worried the wrong person could change a live rule? Give each team its own workspace and roles that match their job.

Compare

Condexa vs spreadsheets

The approval matrix lives in Excel and only Sarah understands it. Compare that with tested, versioned decisions.

Use cases

Purchase order approval

Stop chasing sign-off by email. Encode your delegation of authority once and let the ERP know who must approve every PO.

Make your next rule change the calm kind

Bring a decision your team makes every week. We will build it with you, live, test it against your own examples and show your systems calling it.

Book your 30-minute demo See how it works

No slides. Your decision, built live. No obligation.