Scripting Rule

A Scripting Rule is a native rule type that runs JavaScript inside a sandboxed environment built directly into DecisionRules. You write logic in code as calculations, transformations, conditionals, loops and the engine executes it at runtime like any other rule.

It has the same versioning, testing, and Flow integration as any other rule, but gives you the full flexibility of code when you need it.

Use a Scripting Rule when the logic is fundamentally computational rather than conditional. The clearest signals: you need to reshape or transform complex nested data structures, you need multi-step calculations where intermediate values feed into each other, or you need native JavaScript capabilities like custom sorting or deduplication.

If your problem is "evaluate conditions and return an output," that's a Decision Table. If your problem is "compute and transform data," that's a Scripting Rule.

Scripting Rule requires JavaScript — but the AI Assistant changes the equation. Describe the calculation or transformation you need in plain language, and the assistant generates the script for you.

Not sure if it's right? Ask the assistant to generate test inputs that should return a specific output, run them in the Test Bench, and check the result yourself. No developer required to write it, test it, or validate it.

Yes. DR.solve calls any rule in your workspace — Decision Table, Lookup Table, Decision Tree, another Scripting Rule and returns its output. Always use await and always reference by alias rather than by rule ID. You can also pass a specific version number or override the execution strategy if needed.

See our documentation on calling embedded rules for details.

Yes, using the built-in DR.http methods: get, post, put, patch and delete. Always await these calls and handle the case where the external service is unavailable, your Flow should never depend on an external API succeeding silently.

See our documentation on calling external APIs for details.

Use the built-in Test Bench: paste in a real input payload, run the rule, and inspect the full output directly in the editor. Use log inside your script to surface intermediate values in the debug panel — this is the equivalent of console.log for the sandbox environment. Once the rule is stable, build a Test Suite with representative cases and run the whole suite after every change.

See our documentation on rule testing for details.

Rule Variables are named constants you define in Rule Settings and reference in your script via ruleVariables. Use them for any value that might change independently of the logic: a threshold, a multiplier, a flag, a fee amount. When the value needs to change, update it in one place — no script edits required. Rule Variables are also readable by business users, which makes them the clean handoff point between the code and the people who configure it.

See our documentation on Rule Variables in Scripting Rules for details.

The script will throw an error and the rule will return a failure result. Never assume external calls will succeed; handle failures explicitly in your script.

See our documentation on error handling for details.

JSON only. Unlike Decision Tables, there's no tabular data to export as a spreadsheet. Scripting Rule export captures the full rule definition: the script body, input and output schema, Rule Variables, and version metadata.

See our documentation on rule export and import for details.

Yes, in two ways. If you have access to both spaces, share the rule directly using Share with Space. If you don't, export the rule as JSON and send it to someone who does. After import, the full rule is recreated exactly as it was.

See our Cross-Space Rule Sharing for details.

A Scripting Rule is a first-class node type in any Decision Flow. Wire it in wherever you need custom computation — between a Lookup Table query and a Decision Table, after an AI Agent extraction, or as the final step that assembles outputs from multiple upstream rules. It receives the Flow's mapped input and passes its output forward like any other node.

Yes. Any Flow can call the same Scripting Rule via its alias. Use the alias to always reference the latest published version, so a single publish propagates everywhere — or pin to a specific version if a particular Flow needs to stay on a known state while you iterate.

Technically, a Scripting Rule can chain other rules together using DR.solve — but a Flow is almost always the better choice for orchestration. Flows give you visual clarity, explicit error routing per node, and better auditability.

Keep Scripting Rules focused on computation and transformation. Let the Flow handle the sequencing.

Yes — and there are two types of history. Rule history is auto-saved every time you click Save, capturing your changes in the rule's edit history. You can browse and restore any of these auto-saves at any time. Versions are manual snapshots you create explicitly when making bigger changes. You can compare these versions and roll back to any previous version with one click.

Both types of history give you full safety and control over your data.

See our documentation on Versioning and Rule History for details.

Yes. The Management API supports full Scripting Rule management — create rules, update the script body, publish new versions, and sync from external systems without touching the UI. Useful for teams that manage rule logic in source control and deploy via CI/CD pipelines.

See our Management API documentation for details.

Permissions are fully customizable at multiple levels — space, account, team and roles. You can grant edit access to specific users, restrict others to read-only, or set up approval workflows for production changes.

See our documentation for how to configure granular access control.

Choose a Scripting Rule when the problem is about computation, not evaluation. The tell-tale signs: your data needs reshaping before it's useful, intermediate calculations depend on each other in sequence, or you need raw JavaScript power like custom sorting or deduplication.

If the question is "which rule applies here," use a Decision Table. If the question is "how do I turn this data into that data," use a Scripting Rule.

Three principles: one job per rule, Rule Variables for anything configurable, and log statements for anything you'd want to inspect when something goes wrong. A Scripting Rule that does five different things is five future debugging sessions waiting to happen. Split by concern, call from a Flow, and document it in the rule description so anyone who opens it later knows what it's supposed to do.

Always use Rule Variables for anything that might change independently of the logic — thresholds, rates, identifiers, flags. Hardcoded values make a script opaque to anyone who isn't reading the code, and they require a code edit to change.

Rule Variables surface those values outside the script, where business users can see and update them without touching the logic.