The rules engine, up close

Watch a rule built and deployed in minutes

  • Decision tables your team can read
  • A formula language with 500+ functions

Anatomy of a rule

Every rule follows the same path, and every step happens inside your tenant.

Your Microsoft tenant · Dataverse event pipeline

  1. Event fires

    A record is created or updated, a user clicks a button, a schedule ticks over, or an API call arrives. Any Dataverse event can trigger a rule, whether it comes from Dynamics 365 or a Power Apps app. No code deployment to wire it up.

  2. Decision table evaluates

    Conditions and actions as rows. The engine walks the table and finds the rows that match: logic your analysts, auditors, and AI agents can all read.

  3. Formulas execute

    Matched rows run their actions through the formula language: calculations, record updates, integration calls. Deterministic: same inputs, same outputs, every time.

  4. Result and audit

    Changes are written back to Dataverse and the execution is logged: which rule ran, which rows matched, what changed. The trail your compliance team asks for.

  • No data leaves the boundary
  • The engine executes in the Dataverse sandbox
  • There is no external rules service in the loop

A claims adjudication rule: condition columns in yellow, calculated actions in orange.

A North52 decision table in Dynamics 365: claims adjudication conditions mapped to coverage and message actions.

A claims adjudication rule: condition columns in yellow, calculated actions in orange.

Decision tables

Rules as rows, not code. The grid is the documentation.

Each row pairs conditions with actions, and the table your analysts maintain is the artifact that executes. It isn’t a spec for a developer to implement. It is the rule.

  • Readable by your analysts, your auditors, and your AI agents
  • Versioned like any solution component, with a who-changed-what trail
  • When the rule changes on Thursday, an analyst edits a row: no sprint, no deployment queue
Decision tables in depth ↗

Formula Manager

The engine room behind every cell: an Excel-like language, deterministic by design. Same inputs, same outputs, every time.

500+ functions cover text, dates, math, Dataverse operations, and REST calls to external services. If your team can write a spreadsheet formula, they can write a North52 rule.

That includes the Dataverse AI functions: AIClassify, AISummarize, AISentiment, and AIReply. A rule can classify an email or summarize a case note while the logic around it stays governed, audited, and deterministic.

A sample of functions

  • Text: StringConcat · Left · RegexMatch · Trim
  • Dates: DateDiff · AddDays · CreateDate · GetDateOnly
  • Math: Round · Ceiling · Floor · Abs
  • Dataverse operations: CreateRecord · UpdateRecord · FindRecords
  • Integration: REST helpers for calling external services from a rule
  • AI functions: AIClassify · AISummarize · AISentiment · AIReply, all Dataverse AI called under rule governance
AIClassify · AISummarize · AISentiment · AIReply, all Dataverse AI called under rule governance
Full function reference ↗
rule: route to underwriter
ExecuteAction( 'routeToUnderwriter',
    'contact',
    [contact.contactid],
    SetAttributeAction('priority', 'String', 'Normal')
)

The same action in the Formula Manager, above the decision table that calls it.

The North52 Formula Manager: an ExecuteAction formula routing a contact to an underwriter, above the decision table whose action column calls it.

The same action in the Formula Manager, above the decision table that calls it.

Deploys like any Microsoft solution

Rules are solution components. They move dev → test → prod through the pipelines you already run.

Trigger in real time on the event pipeline, on a schedule, on demand from a button, or via API. Export, import, and version rules with the rest of your customizations.

  • Real-time
  • Scheduled
  • On demand
  • Via API
  • dev → test → prod

A rule set exported through an Azure DevOps pipeline, with a work item ID required on the run.

An Azure DevOps pipeline exporting a North52 credit-card rule set, with previous runs listed and a work item ID required on the run being started.

A rule set exported through an Azure DevOps pipeline, with a work item ID required on the run.

Watch a rule change committed, diffed and deployed through Azure DevOps

Version control and audit trail

Every change committed to source control, linked to the work item that asked for it.

Spreadsheets, emails and exported zip files leave gaps in the record. With North52 and Azure DevOps, a request starts as a work item, a consultant updates the rule, and a pipeline run exports the solution, unpacks it, and commits the files against that work item. The diff shows exactly what changed.

  • See every version of your business logic
  • Roll back to a previous version
  • User and timestamp on every change
The DevOps workflow, step by step ↗

Frequently asked questions

The questions architects ask before they pick a rules engine.

When would we use North52 instead of Power Automate?
Use both. Power Automate is the right tool for linear automation: a record changes, a flow moves it along, an approval goes out. North52 is for the decision inside that process, where the logic is a matrix of conditions rather than a sequence of steps. Pricing, eligibility, validation and routing with hundreds of rules are decision table work, and a flow that tries to hold them becomes hard to read and harder to change.
Can North52 and Power Automate work together?
Yes. A flow can call a rule when it needs a decision, and a rule can start a flow when it has made one. The rules engine works across Dynamics 365 first-party apps, Dataverse, Power Apps, Power Pages and Power Automate, so the decision lives in one place whichever tool reaches it.
Why not just write a plugin?
You can, and for some things you should. Writing the code was never the expensive part. Owning it through every rate change, staff change and platform update is. A decision table is read and changed by the analyst who owns the process, with the change logged. The honest comparison →
Does it run in real time or asynchronously?
Either, chosen per rule. A rule can run synchronously on the Dataverse event pipeline, so a validation or a calculation completes before the save returns, or asynchronously, on a schedule, on demand from a button, or through the API.
Can rules run on forms, without JavaScript?
Yes. Rules can run client side on model-driven app forms and Power Pages forms: show or hide fields, validate input, set values and calculate as the user types, with no JavaScript to write or maintain.
How complex can the rules get?
As complex as the process. One public example is the NFIP Risk Rating 2.0 flood insurance methodology modelled as rules: more than 35 property attributes, over 50 rating tables and more than 1,500 calculations. Rating tables that change over time are managed as data, not rebuilt as logic. See the flood insurance example →
How do we test the rules?
With TestShield, North52's automated testing product. A test arranges the data, runs the process and asserts the result, as Dataverse records, so a change to one rule is checked against every process it touches before it ships. How TestShield works →
Does anything leave our tenant?
No. The engine is a managed solution that runs in the Dataverse sandbox. There is no external service in the loop and no server to host, and rules move dev to test to prod as solution components through the pipelines you already run.
Can external systems call a rule?
Yes. Rules are exposed through the API, so an external application, an integration or an AI agent can ask for a decision and get the same deterministic answer, with the same trace, as a user in Dynamics 365. How agents call North52 →

See it on your own rules

With our team

Personalized demo

30 minutes on your rules, not our slides.

Request a demo

Download and go

Free trial

Full product, your own environment.

Download trial