What is a business rules engine?

A plain-English definition

Every business runs on rules. A customer over their credit limit goes on hold. A purchase order over 10,000 needs the finance director. A supplier without insurance cannot be paid. These rules usually start life in a policy document, a meeting or someone's head, and then end up somewhere a system can apply them.

Very often that somewhere is application code. A developer writes an if statement, and the rule is now part of the ERP customisation, the website or an overnight job. It works, but the rule can now only be read and changed by developers, and only on the next release.

A business rules engine is a separate component whose only job is to hold those rules and apply them. An application asks it a question and gets an answer back. The rules live in one place, in a form that is easier to read, test and change than code, and the application no longer needs to know how the decision is made.

How a business rules engine works

Most business rules engines follow the same basic pattern, whatever the product:

• Inputs (facts): the calling system sends the data the decision needs, such as order value, customer ID, cost centre or country.
• Rules: the engine evaluates conditions against those facts. Rules can be simple comparisons, lookups against reference tables, checks against lists, or several steps in sequence.
• Reference data: limits, bands and lists are usually kept in tables rather than written into each rule, so a number can change without the logic changing.
• Outputs: the engine returns the answer, such as approved, the required approver, a discount percentage or a list of failed checks.
• Explanation: better engines also record which rules fired and why, so the answer can be explained later.

Business rules engine examples

Take the credit rule set in the example on this page. When a sales order is entered, the ERP sends the rules engine two facts: the customer ID and the order value. The engine looks up the customer's current balance, credit limit and any overdue invoices. It then works through the rules in order. If the customer is on the stop list, the answer is hold and credit control is told. If not, it checks whether the order would take the balance over the limit, then whether any invoice is more than 45 days overdue. If nothing applies, the order is released.

The ERP gets back a short answer, such as hold, rule 3, invoice 52 days overdue, and acts on it. It does not know or care how the answer was worked out. When finance decides that 45 days should become 30, they change the rule in one place, test it against a handful of real orders and publish it. The ERP carries on asking the same question and starts getting the new answer.

That separation is the whole point. The application is responsible for the process: taking the order, showing the result, releasing the stock. The rules engine is responsible for the policy. Each can change without the other.

Rules engines are used wherever the same decision is made many times, needs to be consistent and changes more often than the software around it. Common examples include:

• Purchase order approval: who must approve this PO, based on amount, cost centre and category.
• Credit decisions: can this customer have credit, and should this order go on hold.
• Pricing and discounts: what discount can this rep give this customer on this product group.
• Supplier onboarding: is this supplier ready to trade, based on documents, risk and country.
• Eligibility and claims: does this person or item qualify, and which route should the claim take.
• Compliance checks: does this transaction break any policy, and which one.

Benefits, and when you do not need one

The main benefit is that business rules can change at the speed of the business. A threshold moves in minutes rather than waiting for a release. The same rule is shared by every system that needs it, so answers stay consistent. And because the rules sit in one readable place, it is much easier to test a change beforehand and to explain a decision afterwards.

A rules engine is not always the right answer. If a piece of logic is truly part of how an application works, rarely changes and nobody outside IT needs to understand it, it can stay in code. If a spreadsheet is being used for one-off analysis rather than repeated decisions, it can stay a spreadsheet. The signal that you need a rules engine is rules that change often, are owned by the business and have to be explained.

What to look for in a business rules engine

Products range from open-source libraries that developers embed in code to large enterprise platforms. For most organisations the useful questions are practical ones:

• Can the people who own the policy read and change the rules, or only developers?
• Can you test a change with real examples before it goes live?
• Are versions kept, so you know what was live on a given date?
• Is every decision recorded with enough detail to explain it months later?
• How do your systems call it, and how quickly does it answer?
• Does it connect to the data you already have, such as SQL Server or Dynamics 365?

Where Condexa fits

Condexa is a business rules engine built for SMEs and mid-market firms. Policy owners build a decision step by step on a visual canvas, keep limits in lookup tables they own, test it with their own examples and read a step-by-step trace of every answer. Systems call the published version over a REST API and get an answer in milliseconds.

If your rules are currently buried in code, the hard-coded business rules page is a good place to start. For the wider category, see what is a BRMS.