Hard-coded business rules
Stop hard-coding your business rules
Your hard-coded business rules decide who gets approved, blocked or escalated, yet nobody outside IT can read them. Move them into one place the business owns, and let your applications ask for the answer instead.
Incoming request
evaluatingWhy does a £5,000 limit change need a release?
- Look up the customer's price band in the Price bands lookup table
- Trade customers on band B can have up to 12% off list price
- Any discount over the band limit goes to the sales manager for sign-off
- Orders for customers on credit hold get no discount at all
Answer, with the reason
A 10% discount for a band B trade customer is allowed straight away. When sales wants band B to go to 15%, the sales director edits one row in the lookup table, tests it and publishes it the same day. No release needed.
Sound familiar?
Sound familiar?
The policy was agreed in a meeting. Then it was turned into code, and the business lost sight of it.
"It's in the backlog"
Finance wants the approval limit raised from £5,000 to £7,500. It is one number. It still joins the queue behind three features and a bug fix, and ships in the next release if you are lucky.
"Nobody knows what the code actually does"
The developer who wrote the discount logic left two years ago. The rules are spread across a plug-in, a stored procedure and an if-statement nobody dares touch.
"We changed it in one system but not the other"
The same credit rule lives in the ERP, the web portal and a nightly job. One gets updated, two do not, and customers get different answers depending on where they ask.
The quiet cost
What it quietly costs you
- Policy changes that should take an afternoon wait for a release window.
- Developers spend their time adjusting thresholds instead of building what the business actually asked for.
- Nobody can show an auditor the rule that was live last March without reading old code.
- Every change carries the risk of breaking something unrelated in the same release.
Before and after
From buried in code to owned by the business
Today
- Rules hidden inside application code only developers can read
- A policy change means a ticket, a sprint and a deployment
- The same rule copied into several systems, drifting apart
- No record of which version of the rule gave which answer
With Condexa
- Rules laid out step by step on a visual canvas anyone can follow
- The policy owner changes the rule, tests it and publishes it
- One decision that every system calls for the same answer
- Every answer recorded with the version and the reason behind it
How you get there
How you get the rules out of the code
- 1
See the rule in plain sight
Paste an example record and Condexa sets up the shape and a starting workflow. Your team lays out the steps, lookups and checks so finance and IT are finally reading the same thing.
- 2
Prove it gives the right answer
Run it with real examples before anything goes live. The trace shows every step, every lookup and every value, so you can match it against what the old code did.
- 3
Let your applications ask
Publish the decision and your ERP, CRM or Dynamics 365 calls it over a REST API and gets the answer back in milliseconds. The code stops holding the policy and just asks for it.
A worked example
Example: a discount rule pulled out of the order system
A distributor's order screen had discount logic written into it years ago. Sales wants a new band for trade customers, and the change has been in the backlog for two sprints.
The rules, in plain English
- R1Look up the customer's price band in the Price bands lookup table
- R2Trade customers on band B can have up to 12% off list price
- R3Any discount over the band limit goes to the sales manager for sign-off
- R4Orders for customers on credit hold get no discount at all
Condexa answers
A 10% discount for a band B trade customer is allowed straight away. When sales wants band B to go to 15%, the sales director edits one row in the lookup table, tests it and publishes it the same day. No release needed.
Side by side
Hard-coded rules vs Condexa
| Aspect | Hard-coded rules | Condexa |
|---|---|---|
| Who can read the rule | Developers, if they can find it | Anyone with access, laid out step by step |
| Changing a threshold | Ticket, sprint, test cycle, deployment | Edit, test and publish, often in minutes |
| Testing a change | Test environment and a QA cycle | Run it with your own examples and read the trace |
| Same rule in several systems | Copied into each one and maintained separately | One decision, called by every system |
| Explaining an answer | Dig through logs and old code | Every call recorded with inputs, outputs and trace |
| Going back to an earlier rule | Revert code and redeploy | Earlier versions kept and ready to use |
| Who owns the policy | Whoever last touched the code | The team that sets the policy |
FAQ
Questions people ask
What are hard-coded business rules?
Hard-coded business rules are policies, such as approval limits, discount bands or credit checks, written directly into application code. Because they sit inside the software, only developers can read or change them, and every change needs a release.
How do you stop hard-coding business rules?
Move the rule into a separate decision service that your applications call when they need an answer. The application sends the facts, such as the order value and cost centre, and gets back the result. The rule itself can then be changed, tested and published without touching the application code.
Why should business rules be separated from application code?
Business rules change far more often than the software around them. Keeping them separate means a policy change does not need a deployment, the same rule can serve several systems, and the business can see exactly what the rule says.
Is a rules engine better than hard coding?
For logic that changes often or needs explaining, usually yes. A rules engine lets the people who own the policy maintain it, keeps a record of every version and shows why each answer was given. Logic that never changes can happily stay in code.
Do our developers lose control if the business owns the rules?
No. Developers still decide how applications call the decision and which API key each application uses. Workspaces and roles control who can author and who can publish, so changes go live only when the right person approves them.
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.
Read moreCompare
Condexa vs hard-coding
Every rule change is a dev ticket and a release. Compare that with rules the business can change and test itself.
Read moreIntegrations
REST API
Your app needs an answer, not another rules module to maintain. Send the facts, get the decision back as JSON.
Read moreGlossary
What is a business rules engine?
A business rules engine is software that runs an organisation's business rules separately from application code, so the rules can be changed, tested and explained on their own.
Read moreUse cases
Pricing and discounts
Stop discount requests bouncing round by email. Apply price bands and limits consistently and route only the exceptions.
Read moreWhich rule is stuck in your backlog right now?
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.
No slides. Your decision, built live. No obligation.