SQL Server
Take business rules out of your stored procedures
Keep your data in SQL Server and keep your business rules where the business can read them. Condexa decisions read your tables directly, so changing a rule no longer means changing the database.
Incoming request
evaluatingWhich approval band applies to this invoice?
- Look up the approval bands for the cost centre from the SQL Server table.
- Find the band the invoice amount falls into.
- If the supplier is on the watch list, move up one band.
- Return the approver role for that band.
Answer, with the reason
Finance director. CC-410's bands put 12,750 GBP in the 10,000 to 25,000 GBP band, which needs a finance manager. The supplier is on the watch list, so the decision moves it up one band to the finance director, and the trace shows both steps.
Sound familiar?
Why business rules in SQL Server get harder to change every year
Stored procedures were a sensible place to put logic once. Years later, they hold rules nobody outside the database team can read.
Policy hidden in T-SQL
The discount rules are a nested CASE statement in a 900-line procedure. Finance cannot read it, so they cannot tell you if it still matches the policy.
Every change is a database release
Moving one threshold means a script, a code review, a change window and a DBA. Small policy updates wait weeks behind bigger work.
No way to see why
When an order is priced wrongly, you cannot replay the procedure with the values it saw that day. Someone has to guess from the data that is left.
The quiet cost
What logic in the database quietly costs
- Rules drift away from written policy and nobody notices until an audit.
- The one person who understands the procedures becomes a bottleneck.
- A small change risks breaking something else in the same procedure.
- Investigating a wrong answer takes days of detective work.
Before and after
From rules in the database to rules beside it
Today
- Decision logic lives inside stored procedures and triggers.
- Thresholds are hard-coded in T-SQL.
- Changes need a database deployment.
- Past answers cannot be explained step by step.
With Condexa
- Decisions live in Condexa as readable workflows.
- Thresholds sit in lookup tables, which can read your SQL Server tables directly.
- The business edits, tests and publishes a new version.
- Every run keeps a trace of each lookup, value and rule.
How you get there
How Condexa works with SQL Server
- 1
Connect to your databases
Add a SQL Server connection for each environment, such as test and live. Connection secrets are encrypted and never shown again.
- 2
Read your data, not copy it
Point a lookup table at a SQL Server table to use it as reference data, or use a database lookup step to fetch values while the decision runs. The data stays where it is.
- 3
Call the decision instead of the procedure
Your application, or even a procedure that still owns the transaction, asks Condexa over a REST API and gets a JSON answer in milliseconds. The rule itself now lives where people can read it.
A worked example
Worked example: which approval band applies?
A supplier invoice for 12,750 GBP arrives against cost centre CC-410. The approval bands live in a SQL Server table the finance system already uses.
The rules, in plain English
- R1Look up the approval bands for the cost centre from the SQL Server table.
- R2Find the band the invoice amount falls into.
- R3If the supplier is on the watch list, move up one band.
- R4Return the approver role for that band.
Condexa answers
Finance director. CC-410's bands put 12,750 GBP in the 10,000 to 25,000 GBP band, which needs a finance manager. The supplier is on the watch list, so the decision moves it up one band to the finance director, and the trace shows both steps.
FAQ
Questions people ask
Should business logic be in stored procedures?
Stored procedures are good at data work: joins, updates and set-based processing. Business rules that the business owns, such as limits, bands and eligibility, are better kept outside the database, where they can be read, tested and changed without a database release. Condexa is built for that second job.
How do I move business logic out of stored procedures?
Start with one decision. Rebuild its rules as a Condexa workflow, keep its thresholds in a lookup table that reads your SQL Server table, and test it against real rows until the answers match. Then have the application call Condexa instead of the procedure branch, and retire the old logic.
Does Condexa copy our SQL Server data?
It does not need to. A lookup table can read a SQL Server table when the decision runs, and a database lookup step can fetch a value on demand. You can also give a lookup table its own rows or import them from a file if you prefer.
Can we use different databases for test and live?
Yes. Each connection can point at a different environment, so you can build and test against a test database and run the published decision against live.
What is Condexa built on?
Condexa is built on Microsoft .NET and SQL Server, so it fits naturally into Microsoft-based estates. Your applications call it over a REST API, so it works with any language or platform.
Keep exploring
Related decisions and guides
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.
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 moreFeatures
Lookup tables
Every limit change is a dev ticket? Put thresholds and bands in tables your business team edits and publishes.
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 moreChange the rule, not the database
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.