Rules Engine: business rules as workflow JSON instead of C#

Rules that live outside the compiled system

Rules Engine exists because policy changes faster than code does. A discount ladder, an eligibility check, a routing decision: each one ends up hard-coded in C#, and every adjustment becomes a release. Rules Engine moves those decisions into JSON documents that conform to a schema file in the repository, and your code loads them at runtime. The audience is narrow and specific: .NET teams with rule-shaped business logic that product owners or operations staff want to change without touching core logic. It is a library, not a service. Nothing listens on a port and nothing schedules anything. It is also not a general purpose workflow engine. If your logic is a sequence of steps with handoffs, this is the wrong shape of tool, because what it stores is a set of predicates with pass or fail results, not a process graph.

The Workflow document and the schema file it must match

A rule document is a Workflow with a WorkflowName and a Rules array. Every Rule carries RuleName, SuccessEvent, ErrorMessage, RuleExpressionType and Expression. The example policy in the README scores a customer on three fields at once, so one rule is already a compound predicate over an object, not a single comparison. The schema file is the real contract: whichever store holds the rules, the document has to match it. Azure Blob Storage, Cosmos DB, Azure App Configuration, SQL Server, a file system, an Entity Framework table, the library does not care. That flexibility is the design, and it is also where the sharp edges sit, because the rules can live in any store as long as they match the schema. A third-party Blazor editor (alexreich/RulesEngineEditor) ships as its own NuGet package and can be installed as a standalone PWA for offline use, which gives non-programmers an editing surface without you building one.

LambdaExpression rules evaluated against your object graph

The mechanism is thinner than most rule engines and that is the point. Setting RuleExpressionType to LambdaExpression means the Expression field holds a C# lambda expression, so the rule text uses ordinary language syntax with AND in uppercase and field access on the input parameter. The README names that parameter input1, and whatever object you pass in becomes it. There is no rule language grammar to learn, no inference network, no agenda. Evaluation returns a list of RuleResultTree objects that report whether a particular rule passed or failed. The catch is that the rule text now runs inside your application's runtime rather than beside it. Nesting rules is supported, and that is where the cost shows up, as described further down.

Loading the package and building your first workflow

There is no install command to run. The project tells you to download the NuGet package for RulesEngine from nuget.org and reference it into your project, which is the usual Visual Studio or dotnet add package path. The shortest first use builds the workflow objects in code rather than in JSON, which is the easiest way to see the shape of the model. Create a Rule, give it a name, a success message, an error message and an Expression, then collect it into a Workflow named Example Workflow. Here is the whole shape, exactly as the README writes it:

List<Rule> rules = new List<Rule>();
Rule rule = new Rule();
rule.RuleName = "Test Rule";
rule.SuccessEvent = "Count is within tolerance.";
rule.ErrorMessage = "Over expected.";
rule.Expression = "count < 3";
rule.RuleExpressionType = RuleExpressionType.LambdaExpression;
rules.Add(rule);
var workflows = new List<Workflow>();
Workflow exampleWorkflow = new Workflow();
exampleWorkflow.WorkflowName = "Example Workflow";
exampleWorkflow.Rules = rules;
workflows.Add(exampleWorkflow);
var bre = new RulesEngine.RulesEngine(workflows.ToArray());

Once the engine exists, execution is a single call. Pass the workflow name and the input object, and you get the result tree back:

var rulesEngine = new RulesEngine(workflow);
List<RuleResultTree> response = await rulesEngine.ExecuteAllRulesAsync(workflowName, input);

You should see one RuleResultTree entry per rule that ran, with the pass or fail state you set up.

ThenInclude per nesting level, and the wrapper nobody writes for you

Two costs show up when the documents get real. The first is nested rules. If a workflow has rules inside rules, an Entity Framework query needs one ThenInclude appended for each level, and the README snippet shows it with an Include followed by one ThenInclude on the Rules navigation. Deep hierarchies turn one query into a chain that is easy to get wrong and hard to see in a review. The second cost is that the package does nothing about where rules come from. The README is explicit that you must create a wrapper over the engine which fetches rules and input messages from whatever store your system dictates, feeds them in, and handles the output. Cache invalidation, rule versioning and rollback all live in that wrapper, and the README does not document any of them. Decide who owns a bad rule before you ship the first one to a business user.

Where a rule engine stops and a decision table begins

The honest comparison is not with other libraries but with other shapes of rule. A decision table scores many weighted conditions and returns a ranked outcome, so it answers which option wins rather than whether a predicate is true. A state machine describes legal transitions between states and refuses anything not modelled, which catches a different class of mistake entirely. A production rules system such as Drools keeps a working memory of facts and repeatedly fires rules until nothing changes, so the order of evaluation is itself the algorithm. Rules Engine does none of that. It runs the rules you hand it once, returns per-rule results, and leaves the decision of what those results mean to your code. If your rules interact with each other, or if the outcome depends on combining scores, you will be reimplementing one of those systems by hand in the wrapper you already have to write.

The v6 tag and what an upgrade actually costs you

The library is MIT licensed, and the last push to the repository was on 2026-10-28. The newest tag is v6.0.0 from 2025-06-04, with v5.0.6 and v5.0.5 preceding it, so a v5 codebase is looking at a major version jump rather than a stream of patches. That matters because the stored documents are your contract with business users. A major version can change model types, expression handling or the result shape, and every stored workflow becomes a thing you have to re-verify against your real data. The repository layout reflects a serious test and demo arrangement, with separate demo projects including one backed by SQLite through a RulesEngineDemoContext that the README says could be swapped for another provider. That swap is the cheapest way to check a version bump before it reaches your production store.

Editorial conclusion

Adopt Rules Engine if your .NET application already stores policy as documents and you want business owners editing JSON instead of shipping code. Do not adopt it for sequential process logic, for scoring many weighted conditions at once, or for a rules estate you need to migrate without rewriting your loader. Verify first that your loader can serve the Workflow schema from the store you already run, and that nested rules do not force the ThenInclude chain the README describes. Start with the SQLite demo context in the repository if you need a second provider.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/RulesEngine on GitHub
3. Project website
4. README
5. Releases