Rule changes need developers

Change a rule today, not next sprint

You can change business rules without developers when the policy owner edits, tests and publishes the rule themselves. IT keeps control of how systems connect; the business keeps control of what the rule says.

See your decision running How it works

Incoming request

evaluating

Can we raise the credit limit band before month end?

Look up the approval limit for the cost centre in the Approval limits lookup table
Operations (CC-200) can approve up to the limit held in that table
Anything over the limit goes to the director approver
The change is tested as a draft before it is published

Answer, with the reason

The finance controller changes one row from £15,000 to £25,000, tests an £18,000 order and sees it now stays with Operations. She publishes on Wednesday afternoon, and the ERP uses the new limit from the next call.

Sound familiar?

The meeting where everyone agrees, then waits

The decision takes ten minutes. Getting it into the system takes a month.

"Raise a ticket and we'll look at it"

The finance director has approved a new approval limit. Now it needs a ticket, a priority call and a place in the next sprint.

"It'll go out with the next release"

A small change waits for a deployment window, then gets bundled with other changes nobody in finance asked for.

"Can you just do it manually for now?"

While the change waits, people work around the system with emails and overrides. The workaround quietly becomes the real process.

The quiet cost

What waiting on IT really costs

Policy decisions made in the boardroom take weeks to reach the systems that apply them.
Manual workarounds pile up while the change sits in the queue.
Developers lose focus to small rule tweaks instead of bigger projects.
The business stops asking for improvements because it knows how long they take.

Before and after

From waiting in the queue to changing it yourself

Today

Every rule change starts with a ticket
Changes wait for the next release window
Testing happens in a separate cycle run by someone else
Getting it wrong means another ticket to put it back

With Condexa

The policy owner opens the decision and makes the change
Changes go live when you publish, not when IT deploys
You test with your own examples and read the trace yourself
Earlier versions are kept, so going back is quick and safe

How you get there

How the business takes the wheel, safely

1
Own the numbers you change most
Limits, bands and lists sit in lookup tables your team can edit. The rule changes that used to need a developer become an edit to a row.
2
Check it before it counts
Save your change as a draft and run it with real examples. The trace shows exactly how each answer was reached before a single live system sees it.
3
Publish when you are ready
The right person publishes the new version and every connected system uses it straight away. Roles decide who can author and who can publish, so control stays where it should.

A worked example

Example: a new approval limit before month end

The board has agreed that Operations can approve spend up to £25,000 without a director, up from £15,000. Month end is on Friday.

The rules, in plain English

R1Look up the approval limit for the cost centre in the Approval limits lookup table
R2Operations (CC-200) can approve up to the limit held in that table
R3Anything over the limit goes to the director approver
R4The change is tested as a draft before it is published

Condexa answers

FAQ

Questions people ask

How can we change business rules without developers?

Keep the rules in a decision service that business users can edit, rather than in application code. Thresholds and lists go in lookup tables, and the decision is changed, tested and published through a visual tool. Your applications keep calling the same API, so no code change is needed.

Is it safe to let business users change rules?

It is safe when changes are controlled. In Condexa, roles decide who can author and who can publish, changes are tested as drafts first, and earlier versions are kept. Every answer is recorded with the version that produced it.

Can business rules be changed without a deployment?

Yes, if the rule lives outside the application. When a new version of a Condexa decision is published, the applications calling it get the new answer on their next call. Nothing in the calling system needs to be redeployed.

What stops someone publishing a wrong rule by mistake?

Changes start as drafts that can be tested with real examples before they go live. Only people with the publisher role can make a version active. If something still slips through, earlier versions are kept so you can switch back.

Does IT still have a role?

Yes. IT sets up connections to SQL Server or Dataverse, issues API keys to named applications and decides how systems call the decision. The business owns the rule content; IT owns the plumbing.

Keep exploring

Related decisions and guides

Features

Versioning

Nervous about changing a live rule? Draft it, test it, publish it, and keep every earlier version to fall back on.

Features

Workspaces

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

Problems

Hard-coded business rules

Every threshold change is a dev ticket and a release. Move the rules out of the code and back to the people who own them.

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.

Compare

Condexa vs Power Automate

Nested conditions in your approval flow are getting out of hand. Let Power Automate move the work and Condexa decide.

What would you change this week if you did not have to wait?

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.