C# Rule Engine: How to Build a Business Rules Engine in C#

A rule engine in C# keeps business logic - pricing tiers, eligibility checks, approval thresholds - out of the compiled application, so changing a discount threshold doesn't mean a full release cycle. The pattern is simple: evaluate conditions against data, run an action when they match. The decision that's actually hard is which approach fits: own a Rete-based engine in code, evaluate JSON at runtime, or move rule ownership outside the codebase entirely - and each comes with a different long-term maintenance bill.

This guide covers a rule engine c# example for the two real options that are actually .NET libraries, checked against their current NuGet listings and GitHub repos rather than assumed from reputation - and where Nected fits for teams that decide a library isn't the right shape at all.

What Is a C# Business Rules Engine?

A C# business rules engine evaluates business logic - conditions, policies, decisions - separately from application code. The point is straightforward: model business rules C# teams keep changing outside the compiled app, not inline with it. Rules live outside compiled assemblies, so a marketing, finance, or operations team can change one without a developer redeployment. That's a clean definition; it matters in practice the first time someone waits three days on a release just to move a discount threshold.

Use one when:

• Rules change often without a code release - pricing tiers, eligibility conditions, approval thresholds
• Multiple teams own different rule sets and can't wait on a developer for every change
• You need an audit trail of which rule fired, why, and what it returned

Skip one when:

• Rules are stable and rarely change - the overhead isn't worth it for static logic
• The logic is simple enough for plain if-else code - don't add infrastructure a problem doesn't need yet

C# Business Rules Engine Architecture

A C# business rules engine has four moving parts:

• Rule definition - where the logic lives: "if order value exceeds X and the customer is premium, apply a discount." Some systems keep this in JSON, others in code, others in a database-backed table.
• Rule repository - stores the rules, whether that's a file, a database table, a config service, or a remote rule store. Its job is making rules easy to fetch and update.
• Rule evaluation engine - checks input data against stored conditions and decides which rules pass. This is where logic buried across three services usually breaks first.
• Rule execution - runs the action once a rule matches: return a value, call an API, update a record, trigger a workflow. Some engines stop at evaluation; others handle execution too.

Use Cases for a C# Rules Engine

• Loan approval - credit limits, risk scores, eligibility rules
• Pricing - discounts, promotions, customer-specific pricing
• Fraud detection - flagging unusual transaction patterns or repeated failures
• Workflow routing - moving tasks based on status, role, or priority
• Eligibility checks - deciding who qualifies for a service, offer, or benefit

Where C# Rules Engines Get Hard to Maintain

The problems below don't show up with ten rules. They show up once a rule set has been in production for a year and nobody remembers why rule #40 exists.

• Rule sprawl. JSON files or hardcoded conditions get disorganized fast - one update can silently break a rule that depended on the old behavior.
• Ongoing maintenance cost. A custom-built engine is a start, not a finish; business rules don't stop changing once the engine ships.
• Live data wiring. Most rule evaluations need a fact from an API, a database, or another system, and keeping that plumbing clean takes real design work.
• Scale. More rules and more traffic mean more per-request checks - a rule set that was fast at 50 rules can degrade at 500 if the engine re-evaluates everything on every fact.
• A developer bottleneck. If only engineers can safely change a rule, the business waits on engineering for things that aren't really engineering decisions.

Top 2 C# Rule Engines

A quick note on the heading: most "top rule engines" content for C# pads this out to a Top 3 or Top 5 by including projects like Drools.NET, NxBRE, or SRE. All three are real, and all three are dead - no maintained fork, no recent release, nothing to point a production dependency at in 2026. Two libraries come up in every current .NET rules engine conversation for a reason: NRules and Microsoft's RulesEngine. They solve the problem from genuinely different angles, not just different syntax.

Nected isn't on this list, and that's deliberate - it isn't a C# library at all. It gets its own section below.

NRules

NRules is a Rete-algorithm-based, open source rule engine for .NET, MIT-licensed and actively maintained - v1.0.4 shipped in February 2026, with 3.4 million cumulative NuGet downloads. Rules are authored in C# using a fluent internal DSL: no JSON files, no external config.

dotnet add package NRules

public class Order
{
    public decimal Total { get; set; }
    public string CustomerType { get; set; }
    public string Status { get; set; }
}

public class DiscountRule : Rule
{
    public override void Define()
    {
        Order order = null;

        When()
            .Match(() => order, o => o.Total > 500 && o.CustomerType == "Premium");

        Then()
            .Do(ctx => order.Status = "Discount Applied");
    }
}

var repository = new RuleRepository();
repository.Load(x => x.From(typeof(DiscountRule).Assembly));

var session = repository.Compile().CreateSession();
session.Insert(new Order { Total = 600, CustomerType = "Premium" });
session.Fire();

‍

Key Features

• Rete-network matching - the engine tracks partial matches across facts instead of re-checking every rule from scratch on every insert
• Rules are C# classes, so they get full compile-time checking, IntelliSense, and refactoring support like any other code
• session.Insert()/Fire() supports incremental fact updates, which matters once rules start depending on each other's output

Pros

• Genuinely fast at scale - the Rete network is why hundreds of rules against high-frequency data don't mean hundreds of linear checks per fact
• Type safety catches a broken rule at compile time instead of in production, unlike a JSON expression string

Cons

• Every rule change is a code change - a build, a review, and a deploy, which defeats the point if the team that owns pricing logic isn't the engineering team
• The fluent DSL has its own learning curve distinct from plain C#; a developer who's never seen When().Match() needs onboarding time before they can safely add a rule

RulesEngine.NET

RulesEngine is Microsoft's open source library (MIT-licensed, under the microsoft GitHub org) for defining business rules as JSON and evaluating them at runtime - v6.0.1 shipped in July 2026. Because rules sit outside compiled code, they update without a rebuild, which is the main reason teams pick it over NRules.

dotnet add package RulesEngine

[
  {
    "WorkflowName": "DiscountWorkflow",
    "Rules": [
      {
        "RuleName": "PremiumDiscount",
        "RuleExpressionType": "LambdaExpression",
        "Expression": "order.Total > 500 && order.CustomerType == \"Premium\"",
        "SuccessEvent": "ApplyDiscount"
      }
    ]
  }
]

var workflows = JsonConvert.DeserializeObject<List<Workflow>>(
    File.ReadAllText("rules.json"));

var engine = new RulesEngine.RulesEngine(workflows.ToArray());
var order = new Order { Total = 600, CustomerType = "Premium" };

var results = await engine.ExecuteAllRulesAsync("DiscountWorkflow", order);

foreach (var result in results.Where(r => r.IsSuccess))
    Console.WriteLine(result.Rule.SuccessEvent);

Key Features

• Rules are JSON, evaluated as lambda expressions at runtime with no recompilation needed to change a threshold
• ExecuteAllRulesAsync returns a result tree per rule rather than short-circuiting on the first match, so overlapping rules are all visible in one call
• Backed and maintained by Microsoft, which counts for a team weighing long-term support risk on a dependency

Pros

• No rebuild to change a rule, unlike NRules - the JSON file is the deployable artifact for the logic itself
• ExecuteAllRulesAsync returning every rule's result, not just the first match, makes overlapping-rule bugs visible instead of silently swallowed

Cons

• The engine returns a match; it doesn't execute the action. Your code still has to read SuccessEvent and decide what to do - this isn't a drop-in replacement for the "and do X" step NRules gives you natively
• No compile-time checking on the Expression string - a typo in a field name is a runtime failure, not a build error, and overlapping conditions in a growing rule set are easy to miss without dedicated tests against the JSON itself

NRules vs. RulesEngine.NET, at a Glance

Where Nected Fits - Without Being a C# Rule Engine

Both NRules and RulesEngine.NET share the same ceiling: they're libraries, so someone with commit access still owns every rule, and every non-trivial change is a Git-based release even in RulesEngine.NET's "just edit the JSON" case. Neither one gives you versioning, rollback, an audit trail, or a way for the person who actually owns the pricing policy to change it without opening a pull request - that gap doesn't get filled by picking a better library, because it isn't a library problem.

That's the gap Nected fills, and it's the same gap that made it the standout option in Nected's open-source and Python rule engine comparisons: it isn't a NuGet package a C# app references - it's a hosted decision platform the app calls over HTTP, with rule ownership living entirely outside the codebase.

var response = await httpClient.PostAsJsonAsync(
    "https://nected-XX.nected.io/nected/rule/XX-XX-XXX",
    new { customerId = "123", orderTotal = 600 });

What neither NRules nor RulesEngine.NET gives you, that Nected does:

• A business team changes a rule in a visual dashboard - decision tables, condition builders, formula logic - with no developer, no build, and no deploy involved
• Built-in rule versioning and rollback, instead of a Git history someone has to reconstruct after the fact
• A built-in audit trail of which rule fired, why, and what it returned, instead of a logging layer a team builds and maintains itself
• Live data fetched from an external API or database internally before evaluating, so the C# app doesn't have to pre-load every fact it might need

Where a library still wins: every Nected evaluation is a network call, not an in-process function. For microsecond-sensitive, high-frequency decisioning, NRules' local Rete evaluation is the better fit - that's the one real trade-off, not a reason to discount everything above it.

How to Build C#-Level Rules Using Nected

Writing a C# rule evaluator from scratch is a trap most teams fall into once - the first month goes into building the engine, and the next year goes into maintaining the parser instead of the product. Here's what offloading that to Nected looks like end to end:

1. Create a decision table in the Nected dashboard - name it for the domain, e.g., Discount_Workflow_Rules, instead of writing a C# switch statement.
2. Define the input payload - map the JSON keys the C# backend will send (order_total, customer_type, inventory_status), the same way you'd shape a DTO.
3. Set conditions and actions visually: order_total > 500 AND customer_type == "premium" AND inventory_status == "low" → apply a 15% discount and trigger a Slack webhook to the inventory team.
4. Use the formula builder for dynamic math instead of a hardcoded output - discount = order_total * 0.15 rather than a fixed $75.
5. Connect live data - Nected fetches current inventory_status from your database before evaluating, so the rule runs on current data without your app pre-loading it.
6. Test and deploy - run test payloads in the Nected environment, verify outputs, and publish the rule version; the C# app just calls the endpoint.

Bottom Line

Keeping business logic separate from compiled C# binaries is one of the more durable architectural calls a team can make - it's what makes updates, testing, and deployments less risky. Between the two real libraries, the choice is narrow: NRules if the rules are developer-owned and performance is the priority, RulesEngine.NET if JSON-based rules with occasional non-developer edits are enough. But if the people closest to the business logic genuinely aren't developers - and shouldn't have to open a pull request to change a discount threshold - that's a different problem than either library solves, and it's the one Nected is built for.

FAQs

How do you build a rule engine in C#? 

Define the rules, pick a framework (NRules or RulesEngine.NET), load runtime data into a context object, evaluate the rules against it, and run the matching actions.

What are examples of C# rule engines? 

NRules and RulesEngine.NET are the two actively maintained open source options as of 2026 - older names like Drools.NET, NxBRE, and SRE show up in search results but have no recent activity. Nected isn't a C# library at all; it's an API-based platform for when rule ownership needs to live outside the codebase entirely.

Why use a business rules engine C# applications rely on? 

It keeps business logic out of the main codebase, so changes don't require a full redeployment, multiple teams can own different rule sets, and there's a clear record of what fired and why.

What is NRules in C#? 

An open source, MIT-licensed rule engine for .NET using the Rete algorithm. Rules are C# classes written with a fluent DSL, so they get compile-time checking and IDE support - a good fit when rules are developer-owned and performance matters.

What is the difference between NRules and RulesEngine.NET? 

NRules rules are compiled C# classes with full type safety; RulesEngine.NET rules are external JSON evaluated at runtime, so they can change without a rebuild. NRules suits developer-owned, performance-sensitive logic; RulesEngine.NET suits rules that need occasional edits without a full build cycle.

What is RulesEngine.NET used for? 

Pricing logic, eligibility checks, and approval workflows where rules change often enough that a rebuild each time is impractical, but the team is comfortable editing JSON.

How do you install a C# rule engine? 

dotnet add package NRules or dotnet add package RulesEngine. Nected has no NuGet package - the C# application calls its API via HTTP POST, and the engine handles evaluation and returns the result.

‍