Frequently Asked Questions

Integration Flow is a way to create a decision-making process that can be integrated with data sources. For example, it allows you to batch process 1 million of your clients stored in a CRM or database.

For such decision-making processes, we estimate a duration of tens of seconds to hours.

Yes, if you work with large tables, you can export them with a single click to Excel or Google Sheets, where you can edit them and then easily import them back.

If an error occurs during import, DecisionRules will interactively show you which cell needs to be corrected.

All rules and decision-making processes can be exported and imported. Thanks to the built-in folder structure within each space, it's possible to export individual folders or entire projects.

The export format is JSON.

DecisionRules can standardly handle 30,000 records in a single table. This limit is sufficient for most customers. If you need more, this limit can be increased individually.

Decision Flow is a feature within DecisionRules that allows you to create more complex decision-making processes, consisting of multiple smaller decisions, calculations, or external calls.

Decision Flow enables you to combine multiple decision tables, iterate individual decisions, or aggregate data.

For such decisions, we estimate they take milliseconds to seconds.

DecisionRules works with Decision Tables, Decision Trees, Decision Flows, and Integration Flows. These rules are always no-code and user-friendly.

If a more complex data transformation is needed, you can use a Scripting Rule, where you can apply JavaScript.

Yes, they will be. All interested parties can always look into DecisionRules to see how a specific case is evaluated. For broader monitoring, you can easily connect DecisionRules to PowerBI and view individual decisions statistically.

Yes, we have a variety of SDKs available on our DecisionRules Github .

DecisionRules can be integrated using a simple Solver REST API. You simply insert a JSON object as input data and receive the output from the rule in the response. You can find integration examples for individual languages and platforms directly in the application.

Yes, DecisionRules is often used with various integration platforms, such as Power Automate, SAP Platform, n8n, Workato and others. The integration is very straightforward.

Yes, you can. Many customers choose this approach, starting simply with the Cloud variant and then migrating to a Private Managed Cloud or On-Premise solution. The project can be easily exported and imported into the new environment. It takes about 1 minute of your time.

This allows customers to create rules and integrate systems immediately.

Yes, DecisionRules has publicly available Docker containers that anyone can download. It is advisable to use a pre-prepared Docker compose script that will download, install, and run everything directly on your computer. You only need to have Docker Desktop installed, which is available for free.

Yes, DecisionRules is designed to scale. Scaling can be set automatically based on multiple parameters, such as CPU utilization, number of incoming connections, and more. You can easily have an environment that can make tens of millions of decisions per hour.

Yes, DecisionRules uses Redis Cache, which is commonly available. The cache is used as non-persistent. To increase availability, it is possible to use a Redis Cluster.

DecisionRules supports a wide range of private clouds, such as AWS, Azure, or Google Cloud. If you use your own Kubernetes Cluster, DecisionRules will work perfectly for you.

With Private Managed Cloud deployment, you can choose the country where your data will be stored, ensuring it will not leave the selected location. All backups are also kept in the chosen location.

Our average customer can integrate DecisionRules into their system easily within a few hours.

This process takes approximately 5 days from contract signing.

You can choose from more than 30 Amazon Web Services locations where your environment will be available.

Yes, it standardly uses multiple availability zones in individual locations. Thanks to the unique architecture of DecisionRules, it is possible to choose multiple locations that will be automatically selected based on the user's geographical position.

Limits are typically more flexible than in the shared Cloud. Limits are always tailored to the client's needs.

You can choose from more than 30 Amazon Web Services locations where your environment will be available.

DecisionRules offers 3 options:

DecisionRules uses MongoDB or its clones like CosmosDB or DocumentDB for data storage. It is also possible to use Mongo Atlas or your own cluster without problems. Using managed MongoDB is advantageous for database backup, which is a 1-click operation.

Private Managed Cloud is designed for medium and large companies that want to consume DecisionRules as a service under a pre-agreed SLA and have their own dedicated infrastructure that is not shared with anyone.

Most common operational issues can be resolved by DecisionRules itself thanks to its excellent architecture. If any service intervention is needed, our DevOps team will perform it.

Yes. DecisionRules is built to run at enterprise scale, with 99.99% availability and customers processing hundreds of millions of decisions per day. It also supports high-throughput workloads, including tens of millions of solved rules per hour for a single customer, and it automatically scales under higher load.

It’s already used in large organizations, including Accenture, Boohoo Group, Wizz Air and more. If you want concrete examples, here are a few real implementations:

Yes, DecisionRules has extensive publicly available documentation, which we enrich and refine every week. The documentation is available at docs.decisionrules.io .

Yes, DecisionRules has a publicly available academy that guides you step-by-step on how to use DecisionRules. We also provide online and offline training for customers.

Interested in training? Contact us.

No. Anyone with Excel knowledge can use DecisionRules.

Yes, DecisionRules natively versions individual rules.

DecisionRules is suitable for both medium and large companies. If you have issues with changes to configurations, business logic, or decision-making processes, then DecisionRules is the system for you.

DecisionRules saves you money by eliminating the need for developers to change business logic for every business rule modification. All rule changes can be made by a skilled product owner or a junior analyst.

Changes that take days or weeks in organizations can be made in DecisionRules in a matter of minutes. It really works.

Yes, our customers include multinational corporations, financial institutions, and insurance institutions, which are among the most complex organizations in the world. We can handle yours too.

The easiest way is to upgrade to a higher plan. The change takes effect immediately.

Another option is a customized offer tailored to your specific needs. We would be happy to provide you with a tailored offer.

Yes, DecisionRules includes an AI assistant that helps you create all the necessary rules. For example, you can take an internal policy that you need to convert into a decision table, and DecisionRules will automatically create the table based on the policy.

This is the basic unit around which DecisionRules is built: the number of business rules you can create.

In the case of nodes, it refers to the number of nodes you can place in a Decision Flow or an Integration Flow.

The total number of rules and nodes used must not exceed the limit set by your plan.

A Space is a shared area for rules that are somehow related. It's an independent project within DecisionRules that allows you to separate logic for different departments or teams in your company.

The Management API simply serves for automated modifications directly within DecisionRules. You can use it to load data about DecisionRules objects into your system, such as rule names, available versions, etc.

Furthermore, the Management API is used for automated import/export, backups, or integration with CI/CD pipelines.

Access to the Management API is via an API key, which can be obtained directly in the application.

Companies can automate policy workflows by replacing hard-coded rules with flexible, no-code systems like DecisionRules. Instead of relying on long IT development cycles, DecisionRules allows teams to define rule libraries, build dynamic rule sets, and execute them through decision flows without writing code. This approach enables businesses to update and manage policy logic quickly, improve portfolio control, and maintain consistency across all their policy decisions.

Automated policy refers to the process of using a rules engine—such as DecisionRules—to evaluate and enforce policy requirements without manual intervention. In DecisionRules, policies are defined through reusable rule sets, prioritized outcomes, and dynamic decision flows. This ensures that policy checks are executed consistently, transparently, and with full auditability, removing the dependency on IT-driven hard-coded logic.

Credit risk management improves dramatically when companies eliminate rigid, hard-coded rules and move to agile, no-code decisioning using tools like DecisionRules. With DecisionRules, risk teams can maintain a centralized rule library, adjust eligibility and policy rules instantly, test new strategies rapidly, and control decision outcomes through simple configuration instead of development cycles. This agility enables better portfolio quality, faster reaction to market changes, and clearer audit trails for every credit decision.

Banks manage credit risk by evaluating eligibility, applying policy rules, and maintaining consistent decision logic—tasks that become far more efficient with no-code tools like DecisionRules. DecisionRules allows banks to structure their rule library, define outcomes, and run different rule sets (such as eligibility or policy) through the same decision flow. This lets risk teams react quickly, introduce new rules, and adjust strategies without relying on slow IT processes, which is essential for managing large credit portfolios.

Business process automation improves risk management by removing manual steps, ensuring consistent rule execution, and enabling faster updates to risk logic. With DecisionRules, automated rule flows can dynamically evaluate eligibility and policy criteria, collect outcomes, and generate transparent results with full auditability. This reduces operational bottlenecks, supports regulatory compliance, and lets risk teams control decision-making directly—improving both speed and accuracy of risk assessments.

While you can use the HTTP Request node, it requires you to manually handle URL construction, API key management, and JSON parsing for every call. The DecisionRules node provides a native interface with dropdowns for rule selection, centralized credential management, and structured outputs, saving significant time and reducing errors.

Yes, the node itself is free to install from the n8n community nodes registry. However, it requires a DecisionRules account and a valid API Key to connect to your rules, which is subject to your DecisionRules subscription plan.

Absolutely. The node can execute any logic you build in DecisionRules. For simple, real-time decisions, you can use the "Solve Rule" operation. For more complex, long-running processes, you can use the "Start Job" operation to trigger asynchronous Integration Flows.

The management operations allow you to use n8n to programmatically control your DecisionRules environment. This is powerful for CI/CD pipelines, automated testing, or governance workflows, enabling you to do things like update rules, manage folders, and audit rule usage automatically.

The DecisionRules A/B testing pattern is optimized for performance. Group assignment is a fast, hash-based calculation. The primary impact comes from executing different decision paths, which is inherent to the testing process itself

Yes, DecisionRules' flexibility allows for independent A/B testing setups, enabling you to test multiple hypotheses simultaneously without interference.

By logging the assigned Test Group ID as an output parameter, you can easily filter and analyze your historical decision data in your analytics platform to compare key metrics (e.g., acceptance rates, default rates, fraud detection) between groups.

Absolutely. Once a Challenger proves superior, you can easily adjust the percentages in your "AB Testing Setup" table to gradually or completely shift traffic to the winning strategy, effectively promoting it to Champion status.

You can instantly reconfigure the "AB Testing Setup" table to route 100% of traffic to a single, stable group, effectively pausing or ending an ongoing experiment.

They are improving credit risk management by replacing rigid systems with agile decisioning tools like DecisionRules.io. Using controlled A/B testing, they validate new scorecards or policies on small segments, reduce default risk, and maintain clear audit trails. This lets risk teams adjust strategies quickly and base decisions on real performance data.

The answer is, you shouldn't. This approach isn't about abandoning the core functionality of your ERP system. It is specifically about meeting the needs of your business where unique pricing models require extremely short change cycles and the set of conditions in your ERP system is not enough.

You must ensure your ERP system has the necessary API capabilities - specifically, the ability to initiate API calls to external services. Your ERP software vendor may only need to implement this capability once, or it may be available for you to configure.

In DecisionRules, you have a complete testing environment. Before going live, you can test different pricing approaches, and thanks to comprehensive rules management, you can control exactly when new pricing policies will be applied.

Yes, absolutely. DecisionRules includes an Audit Logs feature where all rule calls (when the price is requested) are stored, along with the input and output values. Using the Power BI connector, you can then evaluate how often different pricing policies are applied, which customer segments are evaluated the most, and other key metrics.

DecisionRules.io provides no-code tools for automated affordability checks, risk-based pricing, and APR calculation, enabling small lenders to streamline loan decisions without relying on multiple systems.

DecisionRules addresses fragmentation, slow time-to-market for new products, and inconsistencies in credit decisioning by unifying affordability, pricing, and calculation logic.

No, all DecisionRules templates are entirely no-code, empowering business users (risk, product teams) to manage and adjust lending logic directly without IT intervention.

DecisionRules utilizes dedicated scripting rules and decision tables to accurately compute complex financial metrics such as APR and monthly installment amounts directly within the platform.

Yes, DecisionRules is designed for seamless integration with existing IT infrastructure, allowing you to leverage current data sources and deploy automated logic where needed.

By centralizing all lending logic in transparent Decision Flows and Decision Tables, DecisionRules provides a clear, auditable trail of every decision, ensuring regulatory compliance.

Yes. Through Decision Flows (Workflow orchestration) and Scripting Rules, the engine can handle complex chain reactions. For example, you can chain a Risk Assessment Rule into a Pricing Rule, where the output of the first rule dictates the input of the second.

DecisionRules includes a Test Bench and a Debug Mode. This allows users to run input scenarios against the rule (even in a "Pending" state) to verify the output without affecting the production API. Furthermore, you can use the Rule Comparison feature to visualize exactly what changed between two versions.

Yes. The Solver API is secured via HTTPS/SSL and requires a Bearer Token (API Key). You can manage the lifecycle of these keys (regenerate or revoke) directly in the platform settings.

The best AI-based dynamic pricing software for airlines is one that lets pricing logic update instantly without code changes. DecisionRules enables exactly that by moving all pricing rules into a flexible, configurable Business Rules Engine.

A BRE is software that externalizes pricing and business logic from application code, allowing revenue managers to modify rules without developer involvement.

DecisionRules allows you to combine individual decisioning modules like A/B testing, eligibility rules, scoring, and loan parameters into a single, seamless Decision Flow, providing end-to-end control and transparency.

No-code templates empower risk managers and business users to design, adapt, and deploy complex loan approval logic without IT intervention, significantly reducing time-to-market and increasing agility.

Yes, DecisionRules includes dedicated A/B testing templates that seamlessly integrate into your Decision Flow, allowing you to test different rule variations and optimize your lending strategies in real-time.

Unlike rigid, specialized tools, DecisionRules offers universal business rule engines and flexible templates that provide the full taste of design freedom, allowing you to customize every aspect of your loan approval process to meet specific institutional needs.

A single DecisionRules flow can manage all key aspects of loan approval, including A/B testing, eligibility rule evaluation, score calculation, affordability and loan parameters determination (including risk-based pricing and APR), and policy rule enforcement.

How to build a business rules engine typically involves designing a way to define rules, evaluate conditions, and execute decisions at runtime, which often requires significant development and long-term maintenance. Instead of building and maintaining a custom solution, many organizations choose DecisionRules, which provides a ready-to-use, low-code platform that allows business rules to be created, updated, and deployed quickly without ongoing development effort.

Drools business rules management system is a powerful open-source solution for complex rule processing, but with its technical complexity and reliance on deep developer expertise it is often harder and slower to manage than DecisionRules, which is designed to give business users direct control and faster deployment without sacrificing robustness.

A complex pricing rules engine must handle many inputs, exceptions, and frequent updates, and DecisionRules is built to support this with a visual, dynamic rules designer that lets business teams update pricing logic rapidly without needing development cycles or ongoing IT dependency.

Building business validation rule engine dynamically without heavy development requires a solution that supports rule changes at runtime with proper governance and testing. DecisionRules enables this by letting teams update validation rules through decision tables and flows, making it easier to adapt to changing business and compliance needs.

Most CRM-to-ERP integrations require custom workflows, middleware, or point-to-point connections that quickly become hard to maintain. With DecisionRules, the integration becomes much simpler: both systems send data to a single decision API, and DecisionRules returns consistent pricing, validations, or approval outcomes in real time.

Instead of synchronizing logic between ERP and CRM, you centralize it once — and both systems use the same results.

Workflow automation in CRM systems replaces manual steps — like approvals, data checks, or pricing calculations — with automated rules. The problem is that native CRM automation tools struggle with complex logic and quickly become hard to manage.

DecisionRules offloads that complexity. You design the logic once in a central decision engine, and your CRM calls it whenever it needs pricing, validation, discount approval, or routing decisions.

ERPs are infamous for cryptic “Invalid entry” messages that leave users stuck. Automated validations improve ERP workflows by evaluating data more intelligently, giving helpful guidance, and preventing errors before they cause delays.

With DecisionRules, you can externalize ERP validation rules into a clear, maintainable engine that returns human-friendly messages and correction steps. The result is fewer user errors, fewer support tickets, and more reliable ERP data.

Native CRM rule builders (like Salesforce or Dynamics) work for simple rules but become limiting when logic spans multiple systems or requires versioning, simulations, or advanced conditions.

With DecisionRules, you define business rules in a central, visual interface and call them from your CRM through a lightweight API. This keeps logic out of CRM workflows, makes it easier to update, and ensures consistent decisions across Sales, Finance, CPQ, and ERP.

The only reliable way to unify pricing across CRM and ERP is to centralize pricing rules in one system and let both platforms call it in real time. Otherwise, you end up with duplicated formulas, inconsistent discounts, and manual overrides.

DecisionRules solves this by becoming your single pricing logic engine. Your CRM sends the quote request, your ERP sends the product data, and DecisionRules returns the correct price, discount, or approval instantly — ensuring consistency everywhere.

Workflow automation removes repetitive tasks such as approvals, data checks, territory routing, or discount validation. This reduces manual work and helps teams respond faster.

By using DecisionRules as the logic layer behind your CRM workflows, you automate complex decisions that native CRM tools can’t handle. That means faster response times, fewer errors, and more time for actual selling instead of administrative tasks.

Lookup Tables are a new rule type for storing reference data (like product catalogs) using a primary key for retrieval speed. This makes data access extremely fast and efficient compared to traditional methods.

It enforces the Client Credentials Grant Flow (M2M), replacing static API keys with short-lived JWT Access Tokens. This reduces security risks by ensuring machine-level authentication with tokens managed by Identity Providers like Azure AD, Okta, or Auth0.

A new "Statistics & Limits" dashboard is available in your User Profile. It provides granular breakdowns of API consumption per Space, supports Linked Organizations, and allows data export for external analysis.

Templates have a redesigned UI, offering an "Explore" modal with detailed descriptions and statistics before import. They also benefit from continuous delivery, meaning new patterns are available faster without waiting for full platform releases.

Yes, Lookup Tables support easy data import via CSV files. The system handles column mapping and merge strategies to help you populate or update your tables efficiently.

Agent Mode is a feature in the ChatGPT Atlas browser that allows the AI to actively interact with web pages, such as clicking buttons, typing text, and navigating the UI on behalf of the user.

Yes, while it handled basic tasks well, it hallucinated non-existent rule types and failed to solve complex domain-specific logic problems without human guidance.

Absolutely. DecisionRules offers its own AI Assistant for generating rule structures and functions, which is specifically optimized for the platform, unlike general-purpose browser agents.

The standard version may be free, but the Agent Mode feature tested in this article typically requires a paid subscription or specific plan within the Atlas ecosystem.

Yes. As our test showed, AI is a powerful assistant for speed and onboarding, but it lacks the deep context and strategic understanding that a human Business Analyst provides.

DecisionRules externalizes decision logic into visual rule tables, allowing business experts to maintain rules directly while developers focus on core infrastructure.

The integration with DecisionRules removes hardcoded business logic from application code, eliminating deployment bottlenecks and empowering business users to update rules without full development cycles.

No. While the reference case comes from vehicle finance, the white paper focuses on decision management patterns that apply across financial services, including personal loans, credit underwriting, and collections. The principles described can be reused in any environment where decision logic needs to change frequently.

The white paper provides a practical overview of the decision engine setup, governance model, and implementation approach. It is written for business, risk, and IT stakeholders and focuses on how the solution works in practice rather than on theory or product marketing.

The use case focuses on organizations where underwriting or decision rules are hard-coded in core systems, making changes slow and dependent on development cycles. It shows how separating decision logic into a dedicated decision engine enables faster updates, clearer ownership, and better collaboration between business and IT.

No. While the example is based on underwriting, the same approach applies to other decision-heavy processes such as credit assessment, pricing, eligibility checks, and collections. The use case demonstrates a reusable decision management pattern rather than a single isolated solution.

Yes and no. We don’t provide ready-made n8n workflow templates that bundle entire end-to-end automations. Instead, we provide something more flexible: ready-to-use DecisionRules templates that you can insert into your n8n workflows using our native DecisionRules node.

Our templates follow industry best practices, but we always recommend testing them with your specific data and security requirements before moving to a production environment.

We are finalizing the delivery process for our On-Premise and Docker users. Templates will be available through our web interface, where they can be downloaded and manually imported into Docker or On-Premise environments. This approach ensures full control and security for self-hosted deployments.

Browsing and previewing the library is free. A template only counts towards your rule limits once you choose to import it into your Space.

Yes. Once a template is imported, it behaves like any other rule in your Space. You have full control to modify conditions, add variables, or change the flow logic.

Lookup Tables are stored in-memory within DecisionRules for fast retrieval of structured reference data and don't require external infrastructure. Database Connectors are best for querying live, transactional data from external systems where real-time synchronization with a massive ecosystem is required.

No. One of the main benefits is that business users can update data directly via the UI or by importing CSV files. There is no need for IT involvement, code changes, or application redeployment.

Yes. You can easily import data from .csv files directly into the Lookup Table Designer. The system also validates your data during import to prevent duplicates or errors.

Updates are seamless. Once you save a change to a Lookup Table, all rules referencing that table automatically use the new data immediately. You do not need to redeploy your rule lifecycle.

Lookup Tables offer time complexity, meaning they are extremely fast and comparable to hardcoded values in terms of read speed, but with significantly better maintainability and flexibility.

Absolutely. Any DecisionRules flow can be converted to an Integration Flow to enable webhook capabilities. Simply switch the flow mode in the dashboard, and you can immediately start adding Zapier as an endpoint to your existing logic.

Zapier offers a generous free tier that supports this integration, which is perfect for testing and low-volume workflows. As your automation scales and requires higher execution volume or advanced features like "Paths," you may find their paid plans (starting around $19.99/month) provide the best value for production environments.

For most standard business logic, Zapier’s visual field mapping handles data perfectly. If you are dealing with deeply nested objects or require complex data transformation before reaching DecisionRules, you can simply add a "Code by Zapier" step to your Zap. It usually takes less than five minutes to reshape your data.

Yes, and we highly recommend it. The best practice is to create a separate "Sandbox" Integration Flow in DecisionRules and a corresponding "Test" Zap in Zapier. This allows you to run unlimited simulations with sample data, ensuring your logic is bulletproof before you flip the switch to production.

There is virtually no limit. Because Zapier connects to over 7,000 services, a single `JOB.COMPLETED` event in DecisionRules can trigger a chain reaction: it can simultaneously update a row in Google Sheets, create a lead in Salesforce, send a Slack notification, and generate a PDF invoice in QuickBooks—all from one successful calculation.

Official Helm Charts package DecisionRules and its dependencies into a single, manageable deployment for Kubernetes environments, following industry best practices.

They are built for DevOps teams running DecisionRules on Kubernetes who want faster deployments, easier configuration management, and simpler upgrades.

Yes. All configuration options are managed through a values.yaml file, allowing full control over resources, scaling, and environment settings.

A business rules engine (also called decision rules software or business rules management system) is software that allows organizations to define, manage, and execute business logic separately from application code. This separation makes decision logic easier to update, test, and scale without requiring changes to underlying applications.

Business rules engines handle the "if-then" logic that drives critical business decisions—from loan approvals and insurance pricing to fraud detection and product recommendations. Instead of scattering this logic across multiple codebases, a business rules engine centralizes it in one manageable location.

There are two main types: code-based engines like Drools (requiring developer expertise) and no-code/low-code platforms like DecisionRules (accessible to business users). Solutions like DecisionRules make this approach accessible by enabling both technical and non-technical users to manage rules through a clear, visual interface while ensuring consistent decision-making across systems.

Rules engine software is a specialized application that separates business logic from application code, allowing organizations to define, manage, test, and execute decision rules in a centralized system. Instead of hard-coding business rules into multiple applications—which requires developer involvement for every change—rules engine software stores logic in one place where it can be updated quickly, often by business users themselves.

Modern rules engine software typically includes visual editors for creating rules, version control for tracking changes, testing environments for validation, and APIs for integrating with existing systems like CRMs, ERPs, and databases.

Key benefits include faster time-to-market for rule changes (hours instead of weeks), reduced IT bottlenecks, improved compliance through audit trails, and greater business agility.

Drools is the best free open-source business rules engine, offering powerful rule processing for Java development teams without licensing costs. However, it requires significant Java expertise and ongoing maintenance resources.

For teams wanting a free starting point without technical complexity, DecisionRules offers a generous free tier that includes no-code rule creation, API access, and cloud hosting—making it accessible to both technical and business users.

The best choice depends on your team: choose Drools if you have dedicated Java developers and you do not need rules transparency for business users; choose a free SaaS tier like DecisionRules if you need business users to manage rules independently.

Automated decision making software executes business decisions without manual intervention by applying predefined rules, algorithms, or AI models to incoming data. These systems handle high-volume, repetitive decisions—like credit approvals, insurance claims routing, or fraud alerts—in milliseconds, freeing human experts to focus on complex edge cases.

Unlike basic automation that follows rigid scripts, modern automated decision making software combines business rules with machine learning and real-time data to make contextual, explainable decisions. The best platforms, including DecisionRules, provide full audit trails showing exactly why each decision was made—critical for regulatory compliance in industries like financial services and healthcare.

Key use cases include loan approval process, dynamic pricing, customer segmentation, risk assessment, and compliance checking.

A business rules engine focuses on what decision to make based on conditions and logic (e.g., "if credit score > 700 AND income > $50,000, approve loan"). A workflow engine focuses on how work moves through a process (e.g., "send to underwriter, then to manager for approval, then to fulfillment").

In practice, modern platforms often combine both capabilities. DecisionRules, for example, offers decision tables and trees (rules engine) alongside its Flow feature (workflow orchestration), allowing users to build end-to-end automated processes that both route work AND make decisions at each step.

Choose a pure rules engine if your primary need is complex decision logic. Choose a workflow engine if you need to manage human tasks and approvals. Choose a combined platform if you need both—which most enterprises do.

Building a custom business rules engine typically involves designing a way to define rules, evaluate conditions, and execute decisions at runtime. This requires significant development effort—including rule parsing, conflict resolution, performance optimization, and building management interfaces—plus ongoing maintenance as business needs evolve.

Instead of building and maintaining a custom solution, many organizations choose platforms like DecisionRules, which provide a ready-to-use, no-code environment that allows business rules to be created, updated, and deployed quickly without ongoing development effort. This approach reduces time-to-value from months to days while ensuring enterprise-grade reliability, support, and compliance with security standards such as ISO 27001 and SOC 2.

Implementation time varies dramatically by platform type:

Cloud no-code platforms (DecisionRules, GoRules): Days to weeks. Basic rules can be live within hours; complex implementations with integrations typically take 2-4 weeks.

Traditional enterprise platforms (IBM ODM, FICO): 3-12 months. Requires extensive planning, customization, and IT involvement.

Open-source engines (Drools): 1-6 months. Depends on team expertise and complexity of custom tooling needed.

The fastest path to production is choosing a platform with pre-built integrations, ready-made templates, and professional services support for complex requirements.

Yes, with no-code platforms like DecisionRules, GoRules, and RuleBricks. These solutions provide visual interfaces—decision tables, decision trees, and flow designers—that allow business analysts, product managers, and operations teams to create and modify rules without writing code.

However, not all platforms marketed as "low-code" deliver true business user accessibility. Platforms like Drools, Decisions, and FlexRule still require significant technical knowledge despite marketing claims. When evaluating, always request a hands-on demo with your actual business users—not just developers.

DecisionRules specifically designs its interface for business users while maintaining the power and governance features that IT teams require.

For financial services, the best business rules engine depends on your specific needs:

DecisionRules: Best for banks and lenders wanting no-code flexibility with enterprise compliance (SOC 2, ISO 27001) and flexible deployment options including on-premise.

Taktile: Best for fintechs needing pre-built credit bureau integrations and AI document analysis, but cloud-only.

InRule: Best for regulated institutions requiring explainable ML with full audit trails.

Higson: Best for insurance companies available on-premise.

All four offer the audit trails, version control, and security certifications that financial regulators require. See how First Response Finance implemented DecisionRules

Migration from legacy systems like IBM ODM, FICO Blaze Advisor, or Experian PowerCurve typically involves four steps:

DecisionRules has proven expertise migrating enterprises from legacy BRMS platforms, with Professional Services teams available to accelerate complex migrations. Typical migration timelines range from 4-12 weeks depending on rule volume and complexity.

Based on our rigorous internal testing, utilizing the DecisionRules.io AI Assistant reduces rule authoring time by an average of 60%. This time-saving translates to a 3x increase in daily productivity. Whether you are a total beginner or an experienced professional, DecisionRules significantly accelerates your workflow.

Not at all—in fact, it often improves it! The DecisionRules.io AI Assistant is built to strictly follow Quality Assurance "Best Practices." For example, it easily identifies and extracts legacy Excel formulas to recreate them cleanly within a decision table, resulting in logic structures that are far easier to manage, modify, and understand.

he "comprehension gap" happens when users use conversational AI to instantly generate logic (a concept known as "vibe modeling") and skip the traditional trial-and-error learning phase. At DecisionRules.io, we recognize this cognitive shift: our AI Assistant is designed to automatically handle the complex "how" of rule structures, intentionally freeing human experts to focus purely on the business "why."

While AI excels at creating medium-complexity rules from scratch, massive tables with hundreds of condition rows are better handled with a hybrid approach. The DecisionRules.io AI Assistant expertly builds the underlying logic structure and uses advanced Function Expressions to handle complex cell formulas. From there, users can simply populate the large datasets using our intuitive UI or seamless Excel import features.

The AI Assistant acts as an expert partner within the DecisionRules platform. It helps you analyze complex tables, verify logic, document rules for stakeholders, and navigate the interface more efficiently, reducing the time spent on manual tasks.

Yes. You can paste data from your existing Excel spreadsheets or describe your business logic in plain language. The AI Assistant will automatically generate the corresponding Decision Table structure for you, streamlining the migration process.

You can ask the AI Assistant to create test scenarios instantly. Whether you need random inputs to stress-test a table or specific values to trigger a particular row (e.g., "Create inputs that will trigger row 5"), the assistant generates the data you need to verify your logic.

Absolutely. If you inherit a table from a colleague or need to explain a rule to a non-technical stakeholder, simply ask the assistant, "What does this decision table do?" It will provide a clear, human-readable summary of the input/output models and row evaluation logic.

The AI Assistant is available starting with Release 1.24.0. You can access it directly from the Rules List or within the Decision Table editor by clicking the AI Assistant icon in the top right corner.

A rule engine is a dedicated software tool that allows you to define and manage business logic (like pricing and carrier selection) separately from your main systems. For your business, this means your logistics analysts can update prices or change routes instantly without waiting for the IT department to change the code.

Traditional ERPs and WMS systems are often "rigid." Making changes to their core logic is slow, expensive, and requires developers. A rule engine sits alongside these systems, providing the flexibility to react to market changes in hours rather than weeks, keeping you competitive.

No. These systems are designed for business users, such as logistics planners and analysts. They use intuitive interfaces, such as decision tables and visual flows, allowing your team to manage complex carrier agreements through simple parameters.

Every calculation performed by a rule engine is deterministic and versioned. This means you have a complete, transparent trail of how every cost was calculated. This is critical for carrier invoice verification and financial reconciliation, as it eliminates the "black box" of manual or hardcoded logic.

Yes. Modern rule engines connect to your existing WMS, ERP, or TMS via standard interfaces (like REST APIs). This allows you to modernize your decision-making process without having to replace your entire software infrastructure. See our Integration page for more informationn.

Each stage consists of a Process Flow Layer (the visual flow of steps) and a Decision and Configuration Layer (the parameterization tables and detailed rules).

During Phase 1 (Checks), the engine validates and converts all incoming units (Metric or Imperial) into standardized measurement systems to ensure consistent calculations.

The engine categorizes packages (e.g., standard vs. oversized) and identifies capable carrier types (e.g., Sprinter vs. Linehaul) based on shipment characteristics and carrier capability tables.

Yes. You can configure strategies like "Lowest Cost," "Best Time Ratio," or "Preferred Carrier" as decision rules that evaluate the calculated options to determine the optimal choice.

Integration is handled via REST API. Your systems send a Shipment Request payload, and the engine returns standardized cost and operational metrics (JSON) to feed into your dispatch or invoicing processes.

Migration timelines depend on complexity. A lower to mid-complexity scoring process (one flow with 7 steps, 25 calculated variables, 60 policy rules in 3 rule sets, and a 7-variable scorecard) was migrated in 18 man-days, including conversion, documentation, and testing on approximately 5,000 test cases.

Yes. Scorecard elements such as variable classing and score assignment can be combined into a single Decision Table. The scorecard itself can be assembled using a Decision Flow or a Decision Table, depending on user preference. Final score calculation including transformations and risk grade assignment is handled within the same flow.

Yes. DecisionRules includes a built-in AI Assistant that understands Decision Table logic, can generate rules from natural language descriptions, create test data, generate complex functions for specific cells, explain existing rule logic in plain language, and guide users through building new Decision Tables step by step.

It depends on how much architectural flexibility you need and how many use cases will share the platform. A specialized vertical tool makes sense when you need a single, well-defined process out of the box and you're willing to pay enterprise license costs for vertical depth. A BRMS makes sense when you want to keep flexibility, avoid vendor lock-in, and reuse one platform across multiple processes over time.

The deciding factors are usually: how unique is your logic, how often will it change, how many use cases will share the platform, and how much you value owning it versus renting it. Organizations with a strong CTO or Enterprise Architect voice and a "we'd rather own it" mindset consistently choose the BRMS path.

DecisionRules works for both technical and business-led teams. The initial setup involves IT for integration, but day-to-day rule authoring sits with business analysts, risk teams, or pricing teams in a visual editor. You don't need a large engineering team to run it.

DecisionRules connects to your stack through a well-documented REST API. Your application sends input data, the engine evaluates the rule, and returns the decision. The same pattern works whether you're calling from a CRM, an ERP, a core banking system, a loan origination platform, or a custom application.

For most teams, integration takes hours, not weeks. We provide official SDKs for JavaScript, Node.js, Java, .NET, Angular, React, Python, PHP, Go, and Oracle PL/SQL, plus ready-to-use code snippets inside every rule. There are also native nodes for n8n, Zapier, and Apache Kafka, an Excel Add-In for testing rules against real data, and a native Power BI integration for analytics on rule outcomes.

When you need DecisionRules to pull data from external systems during evaluation, our Decision Flow includes REST API Client nodes and DB Connectors with secure credential management. You stay in control of where data lives and how it flows.

DecisionRules offers three deployment options. Public Cloud runs as SaaS on AWS, with hosting regions in the US and Europe so you choose where your data resides. Private Managed Cloud gives you a dedicated environment with the same managed experience. Self-Hosted lets you run DecisionRules in your own infrastructure via Docker or Kubernetes, including air-gapped environments.

On the security side, DecisionRules is ISO 27001 certified and SOC 2 audited by BDO. Both reports are available under NDA. We're GDPR compliant with a designated Data Protection Officer.

The platform includes audit logging on every rule change and execution, multi-factor authentication, role-based access control with default and custom roles, and SSO integration with your identity provider. Data is encrypted at rest using cloud-managed keys and in transit via TLS. Annual penetration tests are run by independent contractors, and Docker images are continuously scanned with a maximum 14-day remediation window for any identified vulnerability.

For full details and to request our SOC 2 report, see our Trust Center .

DecisionRules has two distinct AI capabilities. They serve different purposes and shouldn't be confused.

The AI Assistant is a build-time tool. It lives inside the Decision Table Designer and the Rules List, and helps your team create and refine rules faster. Paste a credit policy as text, upload a document, or describe a pricing scheme in plain language, and the Assistant returns a structured, editable Decision Table. Inside an existing table, it explains what a rule does in plain language, generates test data that matches a specific row, and writes function expressions for individual cells. Based on our internal testing, this reduces rule authoring time by around 60 percent and translates to a 3x increase in daily productivity for analysts working in tables.

The AI Agent is a runtime rule type. It sits alongside Decision Tables, Decision Trees, Flows, Scripting Rules, and Lookup Tables in our rule catalog, which means you can call it via the same REST API as any other rule. This is for use cases where rule logic benefits from LLM reasoning at execution time, for example interpreting unstructured input before passing it to a deterministic Decision Table.

Your decision logic stays yours. The AI Assistant is built to enterprise standards, with a choice of US, EU, or on-premise data residency, and your data is not used to train external models. For full technical details on the AI Agent rule type, see our documentation .

The AI Assistant is built into the Decision Table Designer and the Rules List. It generates Decision Tables from written instructions, uploaded documents, or structured data, so business logic moves quickly from idea to execution. Paste a credit policy as text, upload a PDF, or describe a pricing scheme in plain language, and the Assistant returns a structured, editable table you can refine.

Inside an existing table, the Assistant explains what a rule does in plain language, generates test data that matches a specific row, and writes function expressions for individual cells based on your description. Based on our internal testing, this reduces rule authoring time by around 60 percent and translates to a 3x increase in daily productivity for analysts working in tables.

Your decision logic stays yours. The AI Assistant is built to enterprise standards, with a choice of US, EU, or on-premise data residency. Your data is not used to train external models.

The AI Assistant is distinct from our AI Agent feature. The Assistant helps you build and understand rules. The AI Agent is a separate rule type used at runtime, alongside Decision Tables, Decision Trees, Flows, and Scripting Rules.

The AI Agent is a native rule type that brings interpretation and reasoning capabilities into your decision processes. Unlike traditional Decision Tables that rely on explicit, hard-coded conditions, the AI Agent leverages large language models (LLMs) to understand context and unstructured data.

Within DecisionRules, it primarily handles three types of tasks:

The AI Agent is not a chatbot—it is a fully integrated component of your decision engine, callable via the same REST API as any other rule. It allows you to automate the ambiguous, language-heavy parts of your business logic that previously required manual human review.

Most teams have a working proof of concept inside two weeks. A first production use case (one process, a few rule sets, integration with one system) typically goes live in 4 to 8 weeks. Migration from a legacy decisioning platform takes longer because of testing requirements, with mid-complexity processes typically migrating in roughly 10 to 18 days of focused work plus regression testing.

You can start without talking to anyone. Sign up for the free tier, build a Decision Table, and call it from your application via API. Most developers have a working rule running inside 30 minutes. If you're evaluating DecisionRules for an enterprise use case, regulated environment, or migration from an existing platform, book a demo and we'll walk through your specific scenario.

Wizz Air uses DecisionRules as a centralized decision layer for operational flight checks. The platform evaluates flight, aircraft, and operational data continuously and returns alerts to the Operations Control Center, helping teams manage by exception instead of manually scanning the schedule.

Before DecisionRules, operational logic was fragmented across legacy systems, documentation, and individual duty managers. DecisionRules helped Wizz Air bring that logic into one transparent place where rules can be managed, tested, and updated directly by the business team.

Wizz Air uses DecisionRules to check roughly 1,000 flights every 3 to 5 minutes across a rolling multi-day horizon. This allows the Operations Control Center to identify potential issues early and act before they disrupt daily operations.

In airline operations, rules can change because of airport requirements, aircraft restrictions, or regulatory updates. With DecisionRules, Wizz Air’s Operations Control Center can update rules without waiting for complex vendor release cycles, giving the team more speed and control.

DecisionRules is well suited for airline operations because it combines scalability, API-based integration, and no-code rule management. For Wizz Air, this means operational rules can be automated, maintained by business users, and connected to internal systems that support daily flight operations.

DRUO uses DecisionRules to manage complex payment logic, including transaction evaluation, risk scoring, fraud detection, and country-specific processing rules. Instead of keeping this logic hard-coded in the platform, DRUO can manage it in a centralized rules engine.

Before DecisionRules, DRUO’s business rules required developer involvement and could take days to update. DecisionRules helped the team move routine rule management into the hands of operations and product users, allowing changes to be made in minutes instead of days.

DRUO operates across multiple countries, financial institutions, and regulatory environments. DecisionRules gives the team a flexible way to manage regional payment logic, risk rules, and compliance-related decisions without overcomplicating the core platform.

DecisionRules allows DRUO’s operations team to create, update, and test rules without writing code. This makes it easier to onboard non-technical collaborators and reduces the dependency on developers for everyday rule changes.

With DecisionRules, DRUO reduced rule update time from days to minutes, saved more than $2,000 per month by reducing developer involvement, and gave operations users direct control over business rules. The platform also added built-in testing, helping the team validate changes before pushing them live.

TMNZ operates in a context where every transaction must be auditable against three pieces of primary legislation, the Income Tax Act 2007, the Tax Administration Act 1994, and the AML/CFT Act 2009. When pricing, billing, and payment-matching rules lived in code, spreadsheets, or undocumented processes, the rules were hard to trace, slow to change, and difficult to audit. By keeping business rule logic decoupled from application code in DecisionRules, the team can author, audit, and update rules independently of feature releases, while keeping a clear traceable basis for each rule.

DecisionRules is a stateless engine that responds to REST API calls, so it slots into an existing architecture rather than replacing it. TMNZ deployed it self-hosted on Azure and called it from .NET microservices through API calls to the DecisionRules solver. The same rules are also invoked from n8n automation workflows, so a single source of truth for the rules serves both the application layer and the automation layer, with no rule duplication between them.

TMNZ connected DecisionRules to its agentic workflows through the MCP Server. This lets AI agents call the same central business rules that the rest of the stack uses, and also introspect and explain those rules through the same interface. In practice, that made complex billing logic easier to debug and helped onboard new team members, because rule definitions could be surfaced in context rather than read out of source code. (Note that the MCP Server and the in-app AI Assistant are distinct features. The AI Assistant helps author and explain rules inside the application, while the MCP Server exposes rules to external AI tooling.)

For a regulated fintech, data sovereignty is a primary concern, and TMNZ wanted full control over where its data sits. Self-hosting DecisionRules on TMNZ's own Azure infrastructure kept the data within their environment and also delivered the low-latency execution needed for real-time financial transactions. DecisionRules also offers Public Cloud and Private Managed Cloud options, so the deployment model can be matched to each organisation's security and compliance requirements.

DecisionRules provides rule versioning and an audit trail, so teams can see which version of a rule was applied and when. Combined with self-hosted deployment, native database integration, and automated testing, this is what allowed TMNZ to align the platform with controls such as ISO 27001. DecisionRules itself is SOC 2 and ISO 27001 certified, with role-based access control, audit logging, MFA, and SSO available. Professional Services are available for implementations and more complex integrations.

A real-time pricing engine calculates prices, discounts, and promotions instantly while the customer is interacting with the basket. With DecisionRules, this logic can be managed as business rules, so e-commerce teams can adjust pricing strategies without waiting for long development cycles.

DecisionRules makes it possible to define discount logic in decision tables and rule flows. This allows businesses to combine product discounts, basket-level promotions, loyalty offers, and campaign rules in one transparent pricing process.

Yes. DecisionRules is designed so business users can create, edit, and test pricing logic in a no-code environment. IT teams remain in control of integration and governance, while business teams can manage everyday pricing changes faster.

DecisionRules can evaluate promotion priorities, stacking rules, exclusions, and eligibility conditions in real time. This helps ensure that the correct discount combination is applied consistently across the customer journey.

Customers expect prices to update immediately when they add, remove, or change products in the basket. A slow or unreliable pricing experience can reduce trust and increase basket abandonment. DecisionRules helps keep pricing decisions fast, accurate, and consistent.

Yes. DecisionRules can use customer segment, loyalty status, basket content, campaign eligibility, and other inputs to calculate personalized offers. This gives e-commerce teams more flexibility to create targeted pricing strategies without hardcoding every scenario.

Yes, we offer our customers global support in 5x8, 24x7 modes, or individual times. You can easily contact support through our Support Portal .

You can handle the implementation yourself without any problems. If you lack team capacity, we can do the first iteration of rules for you or manage them for you long-term.

Of course, our experienced DevOps team will help you install and test DecisionRules on your private cloud. We have done countless installations.

Yes, DecisionRules allows for batch data processing using jobs that can run for several hours. Alternatively, DecisionRules can be used as part of computational processes orchestrated in other platforms.

DecisionRules is built as a robust and high-throughput system. Our infrastructure can effortlessly handle tens of millions of solved rules per hour for a single customer. The platform automatically scales under higher load.

This is the limit on how many rules you can solve within your plan – or, how many times you can successfully call the Solver API.

DecisionRules can evaluate hundreds of thousands of rules per minute. The result may vary depending on individual deployments. Private Managed Cloud or On-Premise deployments offer the best performance because the infrastructure is not shared with other users.

Simple rules have very low latency, around 20ms. More complex rules can have latency around 250ms, and truly complex decision-making processes with dozens of decision tables and external calls can have latency of several seconds.

DecisionRules is the only tool on the market that can utilize multiple data centers located worldwide. This ensures excellent response times, no matter which continent you are on. If you find DecisionRules missing in a certain region, please let us know. We are open to expanding our infrastructure.

DecisionRules is a secure system. All connections are encrypted, and your data is also protected by encryption.

DecisionRules and our processes are compliant with ISO 270001 certification.

DecisionRules and our processes are compliant with ISO 270001 certification.

Yes, we also provide offline licenses.

On-Premise deployment is always an individual matter, where you can set the number of environments, organizations, features, and users you want to have available in your DecisionRules. Our Sales Engineers will be happy to go through your use-case and prepare a tailored solution for you. An unlimited DecisionRules license is also available.

Organization allows for centralized management of projects and users within your organization. You can define teams and permission groups for individual projects. Organization enables login via SAML Single Sign-On, such as Microsoft Entra ID, Okta, 0Auth, etc. This function is especially useful for larger companies with more complex organizational structures.

A Lookup Table is a lightweight data store built directly into DecisionRules. Think of it as a spreadsheet that lives inside your workspace — you define rows and columns, fill it with data, and your rules can read from it instantly. It's purpose-built for small, frequently changing datasets like pricing tiers, country codes, routing rules, or product catalogs that your business logic depends on.

Use a Lookup Table when your data is small (hundreds to thousands of rows), changes often, and needs to be managed by business users without technical skills. Use a database when you're dealing with massive datasets (millions of rows). Lookup Tables sit in the sweet spot between hardcoded values and full database infrastructure — perfect for configuration data, reference lists, and rule parameters that non-developers need to control.

A Decision Table contains your business logic — it evaluates conditions and returns decisions. A Lookup Table contains your business data — it stores values your rules need to reference.

For example: a Decision Table might say if country = US, apply fee structure, while a Lookup Table stores the actual fee values for each country. They work together: your Decision Table reads data from your Lookup Table to make smarter decisions.

CSV, Excel (.xlsx), and JSON. CSV is best for quick data-only imports. Excel files must follow a specific format with headers and data. JSON import is also supported and used for full table exports and re-imports rather than manual data entry.

See our documentation for the required structures and examples.

Yes. When you import a CSV, it merges with your existing data. Rows with matching primary keys are updated, and new rows are added. You can choose whether to automatically create new columns from the CSV or skip them. We recommend creating a new version before major imports so you can roll back if needed.

See our documentation for details.

Yes. When you export to Excel, you'll get two sheets: one with your data and another with the Lookup Table's metadata (version info, timestamps, etc.). CSV export contains only the data itself. Both formats are perfect for sharing, backup, or analysis outside DecisionRules.

DecisionRules automatically validates your data during import and highlights any problematic cells or rows before you confirm the upload. You'll see exactly what's wrong — missing values, incorrect data types, formatting issues — so you can fix them before they go live. This means no surprises and no broken rules.

See our documentation for details on validation rules and how to resolve common issues.

This is an encoding issue. CSV files must be UTF-8 encoded for special characters to display correctly. In Excel, use "Save As" and select "CSV UTF-8" from the format dropdown (not just "CSV"). In Google Sheets, the download as CSV option automatically uses UTF-8 encoding, so you're covered.

Up to 600,000 data points per table (16 MB file size). That means 60,000 rows with 10 columns, or 120,000 rows with 5 columns. This covers the vast majority of reference data use cases — from product SKUs to regional tax rates.

If you need larger datasets, consider splitting into multiple tables or using our database connectors.

Decision Trees export and import as JSON — this captures the full rule definition including your input/output model, all blocks, and version metadata.

There's no spreadsheet-style data to import here.

Yes. Use the Download PDF button in the designer's bottom bar to download a visual snapshot of your tree. This is useful for sharing logic with stakeholders, getting sign-off from business teams, or attaching the decision flow to documentation — no DecisionRules account required to read it.

Yes. Use the Download PDF button in the designer's bottom bar to download a visual snapshot of your tree. This is useful for sharing logic with stakeholders, getting sign-off from business teams, or attaching the decision flow to documentation — no DecisionRules account required to read it.

Excel (.xlsx) and JSON. Excel export is perfect for teams who prefer to work in spreadsheets — even though the Decision Table editor already feels like one, some people simply prefer to do bulk edits in a tool they've used for years. Export your table, make changes in Excel, and import it straight back. JSON is the right choice when you need to migrate rules between spaces, restore from backup, or automate deployments via the Management API.

See our Management API documentation for details.

Yes — two ways. If you have access to both spaces, you can share the rule directly between them using Share with Space. If you don't have access to the target space, export the rule as JSON and send the file — importing it recreates the full rule exactly as it was. The whole process can also be automated via the Management API for teams running deployment pipelines.

See our Management API documentation for details.

Yes. Copy a range and paste it directly into the table with Ctrl+V. If the pasted data goes beyond the current table bounds, new rows are created automatically.

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.

All rule types can reference Lookup Tables. In Decision Tables use Lookup Tables as predefined valid values in cells for easy dropdown selection. In Flows, use the Business Rule node to query Lookup Tables and route logic based on the results. In Scripting Rules, call Lookup Tables directly using built-in functions. The integration is native across the platform — no matter which rule type you're working in, your Lookup Tables are ready to use.

See our documentation for details.

Yes — and this is one of Lookup Tables' biggest strengths. One table can power dozens of rules across your entire workspace. This means that you store your data in one place, instead of duplicating it in several rules, then everyone reads from a single source of truth.

You have complete control. You can configure your rules to always use the latest version — when you create a new Lookup Table version, rules automatically get the freshest data. Or you can lock to a specific version, so rules stay pinned to a particular version even when you update the table. This flexibility lets you test new data safely while keeping production stable.

Not yet — currently you can only retrieve individual rows or values based on a primary key lookup (e.g., get the row where country = 'US'). Full table extraction is on our roadmap and coming soon. For now, structure your rules to query specific rows rather than loading the entire dataset. If your use case requires reading all the data every time, a Decision Table is likely a better fit.

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 name these versions, compare them, and roll back to any previous version with one click.

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

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.

Yes. Use our Management API to automate your Lookup Table workflows. You can update data, publish new versions, sync from external systems, or trigger changes based on events in your application — all without touching the UI. Perfect for nightly data refreshes, integrations with your existing tools, or automated deployment pipelines.

See our Management API documentation for details.

Yes — and there are two types of history. Rule history is auto-saved every time you click Save, capturing your changes as you work. You can browse and restore any auto-save at any time. Versions are manual snapshots you create explicitly when making bigger changes — you can name them, compare them, and roll back with one click. Both give you a full safety net for your logic.

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.

Yes. Use the Management API to automate your Decision Tree workflows — create rules, update logic, publish new versions, or trigger changes based on events in your application, all without touching the UI. This is ideal for automated deployment pipelines or keeping rules in sync with an external source of truth.

See our Management API documentation for details.

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 name these versions, compare them, 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.

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.

Yes. The Management API supports full Decision Table management — create, update, publish new versions, and sync from external systems without touching the UI. Ideal for automated deployment pipelines, nightly data refreshes, or keeping rules in sync with an external source of truth.

See our Management API documentation for details.

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.

Yes. Decision Flows support the same versioning model as other rules in your workspace. You can save versions, restore previous states, and publish updates without losing historical logic.

Access permissions can be configured at multiple levels including spaces, teams, roles, and accounts. You can allow editing, restrict access to read-only, or manage production workflows through your permission model.

Yes. The Management API allows you to create, update, publish, and manage Decision Flows programmatically. This is useful for automated deployments, or synchronizing rules with external systems.

Be descriptive and consistent. Name tables after what they contain: Country Tax Rates not Table 3. Use clear column names: taxRate not value1. Stick to one naming pattern across your workspace — either camelCase, snake_case, or Title Case. Future you (and your teammates) will thank you.

Let the concepts guide you, not the size. Each Lookup Table should represent one logical concept — country codes, pricing tiers, product categories — organized around a single unique primary key. If your data naturally belongs together, keep it together. If it represents two different things, keep them separate.

Lookup Tables aren't relational databases, so don't try to link them. If a rule needs data from two different concepts, query two tables separately. If you find yourself needing joins or cross-table relationships, that's a sign you've outgrown Lookup Tables — use our database connectors instead.

Choose a value that's unique, stable, and meaningful. Use business identifiers like customer ID, product SKU, country code, or employee number — not names, descriptions, or anything that might change. For example: use USD not US Dollar, or PROD-001 not Widget Pro. Your primary key is how rules find the right row, so it needs to stay consistent.

Let the business logic guide you, not an arbitrary limit. Nesting is powerful, but very deep trees can become hard for teammates to audit and maintain. If you find yourself beyond five levels of nesting, consider whether part of the logic belongs in a separate rule — a sub-tree called from a Flow — rather than all in one tree. Clarity beats compactness.

Split by concept, not by size. Each Decision Tree should model one decision — eligibility, routing, risk classification — with a clear input and a clear output. If your tree is making two unrelated decisions at once, that's a signal to split. Smaller, focused trees are easier to test, easier to explain to stakeholders, and easier to reuse across different Flows.

Three things: a clear input/output model defined before you start building, consistent branch naming that mirrors how the business talks about the decision, and an ELSE block at every level where an unmatched input is possible. Test with real-world edge cases — not just the happy path — before publishing. Use Debug Mode to confirm the engine is walking the tree exactly as you intended.

The test suites are mostly for organization, they also make it easier to select a group of tests with just one click. The number of the test suites that are created is up to the user, so whatever makes your life easier is the best.

Running selected tests is mainly recommended when either fixing errors or designing the rules, it is a useful tool to quickly see that the changes you are making actually fix the errors you are trying to fix.

After you are content with the rules, it is recommended to Run all tests to make sure that everyting works as expected. Running all test is also useful when preparing for migrations, you can run all the tests in the space to make sure that the rules are production ready.

It can happen, that your rule return in its output some dynamic field that will always cause the test to fail ( imagine returning the current date, such a test would only work for 24 hours). Because of this each test has the option to select Ignored outputs, where you can select output fields that will not be counted towards the failure of the test and will be omitted from the output comparison.

Browse the library by industry or category in the left sidebar, or use the search and filter to narrow by name or tag. Click Explore on any template to read the "About This Template" section — it explains the solution components, how the rules connect, and what the logic does.

After importing, open the rule and check that the input/output model matches the data your application sends. The most common issue is a mismatch between the attribute names in the template and the field names in your own system — for example, a template using countryCode while your API sends country. Use the built-in Test Bench to run the rule against a real sample payload immediately after import.

See our documentation on the Test Bench and input/output model for details.

Let the logic guide you, not the size. Each Decision Table should represent one decision — pricing, eligibility, routing — with a clear input and a clear output. If two unrelated decisions are sharing the same table, split them. Smaller, focused tables are easier to test, easier to hand off to a business owner, and easier to reuse across different Flows.

That said, there are also hard limits to keep in mind: a single table supports up to 40,000 rows, 40 columns, and 80,000 cells. If you're approaching those boundaries, splitting is the right move regardless.

See our Structure Limits documentation for details.

When the same values appear across multiple rules, or when the data changes more often than the logic does. If you're hardcoding fee amounts, country codes, or product configurations directly into table cells, any change means editing the table itself — and potentially breaking the logic. Move that data into a Lookup Table, reference it from your Decision Table, and updates become a data change rather than a rule change. Business users can update the values independently without ever touching the logic.

See how to use Lookup Table with Decision Table in our documentation .

Whenever a value is used in more than one place, or whenever a non-developer might need to change it. Rule Variables let you define a value once — a promo code, a threshold, a multiplier — and reference it across the entire table. When the value needs to change, you update it in one place in Rule Settings and every row that uses it updates automatically.

No hunting through cells, no risk of missing one.

Save constantly — every save is captured in Rule History and can be restored at any time. Create a named version when you're about to make a significant structural change, before a major data import, or before publishing to production. Think of saving as autosave and versions as a manual snapshot before something important.

Versions also give you precise control over which rules call which data. One process can always call the latest published version, while another stays locked to version 3 and a third to version 5 — all from the same table. This makes it safe to iterate and test new logic without affecting any caller that isn't ready for the change yet.

Specificity. "Duration of the initial contract term in months" consistently outperforms "contract duration." If a field has a fixed set of valid values, list them in the annotation. If it requires a judgement call or calculation, explain the logic. If the field could be confused with something similar, clarify the distinction.

The annotation is the instruction the model follows when filling that field, treat it like a brief to a careful analyst, not a label on a spreadsheet column.

Use the built-in Test Bench. Paste in a real sample input and run the rule directly in the editor, you'll see the full structured output and can inspect every extracted field before anything goes live. Once the rule is stable, build a Test Suite with a range of representative inputs and run it in one click after every change.

For fields where the output is a fixed value: a boolean or a number. You know exactly what a correct result looks like and can assert it directly. For fields that produce open-ended text: a summary, an analysis, a narrative. Mark them as ignored in the test so they don't block the run.

Let the schema do the heavy lifting. A short, clear prompt: role, context, task. Combined with precise, well-annotated output fields consistently outperforms a long, elaborately engineered prompt with a vague schema.

The prompt tells the model who it is and what it's looking at. The schema tells it exactly what to return. If your output is inconsistent, the fix is almost always in the annotations, not the prompt.

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.

A good Decision Flow keeps responsibilities separated. Each node should do one clear job — validate data, evaluate a rule, enrich information, or transform outputs.

The Flow itself should focus on orchestration, not hiding massive logic inside one oversized node.

Keep nodes focused and predictable. Each node should ideally perform one clear responsibility — validate data, evaluate a rule, enrich information, transform outputs, or call an external service.

Avoid creating nodes that try to do everything at once. Smaller, specialized steps make the Flow easier to read, easier to debug in Inspect Mode, and much safer to modify as the process evolves over time.

Yes. Migration from legacy decisioning platforms to a modern BRMS like DecisionRules is possible and has been done successfully by financial institutions. The process involves analyzing the existing rule repository, aligning on an IO model, converting rules using established patterns and templates, and testing against original test cases. Many rule types (scorecards, policy rule sets, class sets, matrices) can be converted in a semi-automated way. A typical mid-complexity conversion of a credit card scoring process takes approximately 10 to 18 man-days including testing.

Yes. DecisionRules supports in-app testing, testing directly from Excel using an Add-In, bulk testing via Python scripts, and REST API-based testing. This eliminates the need for IT resources to transform test data between formats, which is a common bottleneck with legacy platforms.

DecisionRules is cloud-native and can be deployed via Docker or Kubernetes in any private cloud environment (AWS, Azure, GCP), or used as a public SaaS. This contrasts with legacy platforms that traditionally require on-premise deployment or managed-service implementations with longer setup timelines.

A specialized lending decisioning tool comes with pre-built rule types for credit risk (scorecards, policy rules, decision setters) but offers limited customization and typically requires scripting for anything beyond the built-in components. A universal business rule engine like DecisionRules provides a smaller set of flexible, general-purpose rule types (Decision Tables, Decision Trees, Decision Flows) that can be combined using templates and orchestration to replicate and extend the same lending logic, entirely without code.

Yes. DecisionRules enables fully no-code design of policy rules, scorecards, risk-based pricing, affordability calculations, and A/B testing. Scoring variables and score assignment can be defined within a single Decision Table. Policy rules are designed visually rather than as scripting expressions, making them accessible to Risk analysts without developer support.

DecisionRules offers transparent, tiered pricing including a free tier for testing. Unlike legacy platforms that often have opaque enterprise licensing with multiple licence levels (from limited parameter changes to full design access), DecisionRules provides complete platform access with every licence. There are no vendor lock-in costs, and the lightweight cloud-native architecture significantly reduces infrastructure requirements.

Yes. DecisionRules is a universal business rule engine suitable for any industry, including e-commerce (dynamic pricing), logistics (shipping rules), insurance (underwriting), and more. Financial institutions that start with credit decisioning often expand to data validation, fraud detection, dealer management, product pricing, and other processes that were previously hard-coded.

A credit decisioning platform is a system that automates the evaluation of loan or credit applications. It processes applicant data through a set of business rules, scorecards, and policy checks to produce decisions such as approve, decline, or refer. Traditional platforms come with pre-built rule types specific to lending. Modern alternatives, such as universal business rule engines, achieve the same outcomes using flexible, general-purpose rule types like Decision Tables, Decision Trees, and Decision Flows that can be configured entirely without code.

A BRMS allows organizations to define, manage, and execute business logic separately from application code. In financial services, it is used for credit scoring, policy rule evaluation, affordability calculations, risk-based pricing, and limit assignment. A modern BRMS like DecisionRules enables Risk analysts to design and modify all of these components visually, without developer involvement.

A BRMS is software that lets organizations define, manage, and execute business logic separately from application code. Instead of hard-coding policies, pricing tiers, eligibility checks, or scoring models inside individual systems, teams maintain them in one place and call them through APIs.

This separation matters because business rules change far more often than the systems that use them. A bank might update its risk thresholds quarterly. An insurer adjusts underwriting criteria by region. An e-commerce platform tweaks pricing rules weekly. With a BRMS, those updates happen in a visual editor and go live without a software release.

DecisionRules is a cloud-native BRMS built around Decision Tables, Decision Trees, Decision Flows, and Scripting Rules. It evaluates rules through a REST API and is used across credit scoring, pricing, fraud detection, eligibility, and routing in financial services, insurance, e-commerce, healthcare, and logistics.

The most important features include no-code rule design (so Risk teams can make changes independently), support for scorecards and policy rule sets, built-in templates for common lending components (risk-based pricing, affordability, A/B testing), flexible rule orchestration, rule versioning, API-based integration, in-app and Excel-based testing, and an audit log for regulatory compliance. Additional differentiators include AI-assisted rule creation and the ability to handle missing values in input data.

An AI assistant embedded in a decisioning platform can generate rules from natural language descriptions, explain existing rule logic in plain language, create test data automatically, and help debug complex conditions. This significantly reduces the time needed to build and maintain credit strategies, especially for teams that update their rules infrequently and may lack deep familiarity with the tool.

Universal business rule engines offer a viable alternative. Instead of relying on pre-built but rigid rule types, they provide a small set of flexible building blocks (Decision Tables, Decision Trees, Scripting Rules) combined with powerful orchestration. Templates for lending-specific patterns, such as scorecards, policy rule sets, risk-based pricing, and affordability calculations, make the transition straightforward. The key advantages are significantly lower licensing costs, full no-code design, and the freedom to use the same platform for other business processes beyond lending.

A specialized tool offers pre-built rule types designed for credit risk but limits customization. If your needs go beyond the built-in components, you typically have to resort to scripting. A universal rule engine takes the opposite approach: fewer rule types, but each is highly flexible and can be combined to replicate any lending pattern. Policy rules are designed visually instead of as code expressions, scoring variables and score assignment happen in a single table, and rule orchestration is fully customizable through Decision Flows.

The difficulty depends on the complexity of the existing rule set. Many common rule types (class sets, matrices, scorecards, policy rule sets) can be converted in a semi-automated way using established conversion patterns. A typical mid-complexity migration, covering a scoring flow with 25 calculated variables, 60 policy rules, and a scorecard, takes approximately 2 to 3 weeks including documentation and testing. The conversion preserves the original IO model and outputs, enabling direct comparison testing against the legacy system.

Modern rule engines like DecisionRules use a REST API for integration, accepting JSON inputs and returning JSON outputs. This is simpler than legacy platforms that often require Java library integration or compile-based deployment. The input data model supports missing values, so no complex data transformations are needed before calling the engine.

Yes. Financial institutions have successfully migrated their credit card and loan scoring processes to DecisionRules, including scorecards, policy rules for decline and referral, income calculations, debt ratio assessment, and limit assignment. In one case, the migration was completed in 18 man-days and validated against approximately 5,000 original test cases. After migration, the institution also expanded usage to budget calculations and data validation processes that were previously hard-coded. See all case studies here .

Legacy specialized platforms typically use opaque enterprise licensing with multiple tiers (from limited parameter changes to full system design access), plus significant implementation costs. Modern rule engines offer transparent tiered pricing. DecisionRules provides a free tier for testing, a public cloud subscription for growing businesses, and an enterprise/self-hosted option for high-volume needs. Every tier includes full platform functionality with no feature restrictions based on licence level.

The biggest cost drivers in legacy platforms are licence fees (especially for full design access), heavy IT involvement in testing, and vendor lock-in. Switching to a lightweight, cloud-native rule engine reduces all three. DecisionRules eliminates tiered licensing, enables Risk teams to test directly from Excel without IT support, and runs on standard infrastructure (Docker/Kubernetes) in any cloud environment, removing dependency on a single vendor.

DecisionRules provides a complete audit log of all rule executions, rule versioning to track every change, and a Business Intelligence API for connecting with external BI tools. Rules are designed visually, making them easier to review and explain to regulators compared to scripting-based logic. The platform also supports A/B testing for champion/challenger strategy validation.

Best practice is to test rules at multiple levels: individual rule testing within the platform, bulk testing using real or generated test data, and comparison testing against the previous system's outputs. DecisionRules supports all of these: in-app testing for individual rules, Excel Add-In for bulk testing directly from spreadsheets, REST API testing for integration validation, and AI-generated test data that targets specific rule conditions.

A Decision Tree is a visual rule type built directly into DecisionRules. Think of it as a flowchart that lives inside your workspace — you define IF/THEN/ELSE blocks, nest them as deep as you need, and the engine walks the tree at runtime to produce a result. It's purpose-built for decisions that branch: approval logic, routing, eligibility checks, risk scoring, or any process where the next step depends on the answer to the previous one.

Decision Trees work best when the path through a decision depends on intermediate answers — approval workflows, eligibility checks, risk classification, dynamic pricing logic, or any process where earlier conditions determine which later conditions even matter. If your team describes the logic as first we check X, then depending on that we check Y or Z, a Decision Tree captures that naturally.

Use a Decision Tree when your logic branches — when the path through the decision depends on the outcome of earlier conditions. Decision Trees shine for sequential, multi-level reasoning where one answer unlocks the next question. Use a Decision Table when your logic is parallel — when you're evaluating many combinations of inputs against a flat set of rules and returning a result. If your logic reads more like a flowchart than a spreadsheet, Decision Tree is the right fit.

Any rule type in your workspace can call a Decision Tree using the built-in SOLVER function — Decision Tables, Scripting Rules. The most common pattern is wiring a Decision Tree as a node inside a Flow, where it handles the branching logic as one step in a larger automated process.

Yes — but the recommended pattern is to handle that orchestration in a Flow. There, you can sequence rules in any order: run a Lookup Table to fetch reference data, pass the results into a Decision Tree, then hand off to a Scripting Rule for further processing. Each rule stays focused on one job, and the Flow connects them.

Calling other rules directly from inside a Decision Tree is possible by using SOLVER function, but using a Flow gives you better visibility and control over how rules interact.

Yes. Because any rule can call a Decision Tree via SOLVER, the same tree can power logic across multiple rules or Flows. You maintain the branching logic in one place, and every caller automatically gets any updates you publish.

Use an ELSE block. The ELSE block is triggered whenever none of the preceding IF conditions in the same level are satisfied. It's your catch-all — the fallback path for any input that doesn't match a defined branch. Without an ELSE block, inputs that don't match any condition simply produce no output for that branch. Always add an ELSE block when you need a guaranteed response for every possible input.

A test is a small collection of several key pieces of information - the input data, expected output data and the strategy of execution. Such a test can be executed and the system then compares the results of the current rule to the expected results of the tests and give you either just a success or a comparison of differences between the real output and the expected.

Test suites are just organizational units for tests. You can think of them as folder in Decisionrules, they mostly allow for better understanding of the test , separate test into logical blocks and make it easier to batch manage tests if necessary. They also make selecting a group of tests to run much easier.

When you run a set of test a test run is created, when the execution finished you will find all the results of your tests in this run. You can execute only one test, multiple or all of them, in either case the test run will be where you find your results.

There are several menus for tests each of them with a specific purpose. In any rule ( except Integration flows and Lookup tables ) you will find the Tests tab right next to designer - this is a place to manage and execute tests for your rule. In the left panel of the rule you will find a list of your executed test runs and you can visualize the results right in the rule for debugging. Lastly in the Space - tests menu you can manage and run tests for the entire space at once.

For creating tests you have several options, the easiest one is available right in the test bench where you can save your execution as test without having to paste everything manually, you can create the test from scratch in the tests panel or you can use the API.

Regular users of Decisionrules are used to the Test bench, which allows them to fill in data and visualize the execution of the rule right in the UI. For any such execution you are provided an option to “Save as Test” and after selecting a test suite in which the test is created and a name you will have created your first test without having to paste in everything by hand. This way you can also be sure that the test fits the current rule perfectly.

When the UI is not enough for the creation of the test ( maybe you have too large of a number of test to input them manually ) you can take advantage of our test API. This API will allow you to Create, update, delete and export tests as you would expect and is a part of the Management API sharing the same API keys.

For running tests you have a few options depending on what you want to achieve. If you want to tests a particular rule, for example after making some changes, you can go into the Tests panel and either select the tests you want to run and click “Run selected”, or just click “Run all”.

If you want to run tests across multiple different rules, you can do this via the Space menu - Tests. This menu works the same way as the rule level panel does, but allows you to select tests across all the rules in the space or just run all available tests in the space.

Any test execution creates a Test Run, these can be either seen in the space level menu ( here you will see all runs across the space ) or in the left panel in the rule designer which will have all the Test Runs which contained any test from the particular rule.

When you open up the test run and select a particular test that failed you will see a comparison of the expected results ( what was defined in the test ) and the actual output which the current rule gave.

When looking at the test results ( whether in the space menu or in the rule ) you have the option to inspect. If you select this , you are taken into the rule and the data of the test in loaded into the test bench. At the same time you will see the visualization of the executed logic as if you ran the rule with Debug option.

What is recommended is that after the tests are ran and some fail, the user should visualize the results to be able to determine why the logic doesn’t work the way it is expected. After they find the mistake, they can fix it and rerun the test just using the test bench ( this does not create the test run, but the test bench will contain a badge notifying the user about whether the output conforms to the preexisting test ). After making changes it is recommended to rerun all tests again to make sure that some fixes did not accidentally affect other tests.

A Template is a pre-built, fully functional rule - or set of rules - that you can import directly into your workspace. Each template is built around a real business use case: loan approval, insurance pricing, fraud detection, product recommendations, and more. Templates are designed to be explored, run, and adapted - not just read about. They're the fastest way to understand how DecisionRules works in practice and to get your first rule live without starting from scratch.

Use a Template when your use case is close to something in the Templates library — pricing, scoring, routing, fraud detection, eligibility, insurance quoting. Even an imperfect match is worth importing, because adapting an existing structure is always faster than designing the input/output model, rule logic, and flow orchestration from zero. Build from scratch when your logic is genuinely unique, has no analogue in the library, or when you have a very specific architecture in mind that a template would only get in the way of. When in doubt, import the template first — you can always delete it and start fresh.

Don't see your use case covered? Submit a request through our support portal and it may shape what we build next.

A Template is an importable rule or rule set — the business logic itself, ready to be brought into your workspace and adapted. A Sample App is a featured template that also includes a live, interactive front-end built on top of that rule. Sample Apps let you configure real inputs — trip details, loan parameters, passenger counts — and see the DecisionRules API return actual results in real time, directly on the template page, before you import or log in to anything. Both can be imported and customised freely; Sample Apps just come with a richer preview experience that shows the rule working end-to-end in a real application context.

Browsing, exploring, and importing templates is free. However, some templates include rule types that require a paid plan to run. Each template detail page shows which rule types it contains, so you can check before importing.

If you're unsure what your plan includes, check your subscription settings or reach out to support .

Yes. Every template has an Explore button that opens a detail page with a description, screenshots of the rule structure, and a breakdown of the solution components — what rule types are used, how they connect, and what the logic does.

Sample Apps go a step further — they show you the full end-user experience. A customer fills in a form, clicks a button, and DecisionRules handles everything behind the scenes: the engine evaluates the rules and returns a result that appears as a clean, readable output on screen. It's the clearest way to understand what your own application could look and feel like before you write a single line of integration code.

Open the template page, click the Import button, and the rule — or full set of rules — is added directly to your workspace. For multi-rule templates, the entire folder structure is imported, including all Decision Tables, Flows, and supporting rules, organised exactly as they appear in the example. From there you can explore, edit, test, and publish at your own pace.

Yes — and that's exactly the point. Also the AI Assistant can help you tailor it to your needs. Once imported, you own the rule entirely: adjust conditions, swap values, add rows, change the output model, connect it to a Lookup Table. The structure is already built so you can focus on adapting the logic to your specific business, not on setting up the scaffolding from scratch.

Yes. Once a template is imported and adapted in your workspace, it's a fully standard rule — and like any rule in DecisionRules, you can export it as JSON for backup, sharing, or migrating between spaces. Decision Tables can also be exported to Excel. If you want to share your customized version with a teammate or move it to a different workspace, use the standard rule export.

See our documentation on rule export for details.

Templates span insurance, financial services, e-commerce and retail, education, healthcare, aviation, industry, and logistics. Within those categories you'll find use cases like travel insurance quoting, flight ticket pricing, loan calculation, AML screening, fraud detection, product recommendations, portfolio rebalancing, parcel routing, applicant scoring, and more. The library is growing each quarter with new industry-specific examples.

Don't see your industry or use case? Let us know via our support portal.

Industry templates are built around real business problems — insurance quoting, fraud detection, loan approval, parcel routing — and are designed to be adapted for production use. Easy Start templates are designed for learning: they demonstrate specific platform features and patterns in the simplest possible way, so you can understand how something works before applying it to your own logic.

If you're new to DecisionRules, Easy Start is the right place to begin. If you have a specific use case in mind, go straight to the industry templates.

Templates use every rule type available in DecisionRules: Decision Tables for structured condition-outcome logic, Decision Flows for multi-step orchestration, Decision Trees for branching paths, and Scripting Rules for custom calculation logic. Many templates combine several rule types in a single folder - this is intentional, so you can see how rule types work together in a real-world architecture, not just in isolation.

If you have a use case you'd like to see covered, reach out to our team via support . The template library roadmap is actively shaped by customer needs — and if your use case is a good fit, it may appear in an upcoming release.

A Decision Table is the most popular rule type in DecisionRules — and the first one most teams reach for. It turns business logic into a structured grid where each row is a scenario: a specific combination of conditions that leads to a defined output. Pricing tiers, eligibility rules, fee structures, approval logic, tax rates, routing rules — if your logic can be written in a spreadsheet, it belongs in a Decision Table. No code, no developer required to build it or maintain it.

Decision Tables have three column types. Input columns hold the conditions evaluated against incoming data. Output columns hold the values returned when a row matches. Calculation columns are intermediate columns that compute a derived value per row — think of them as named variables scoped to that row's evaluation. They keep your table clean by avoiding repeated formulas across multiple output columns, and their value can differ per row while staying consistent within it.

See our documentation on Table Designer for details.

Operators define how each condition in a row is evaluated against the incoming data. You pick the field from your input model, choose an operator, and set the value to compare against — every condition in a row must pass for it to match and return its output. Operators cover everything you'd expect: equals, not equals, greater than, is null and more.

Two special operators are worth knowing: ANY makes a condition always pass regardless of the input value; ELSE triggers only when no other row in the table has matched — the cleanest way to define a default or fallback response.

See the full list of Basic operators and Date operators in our documentation.

A Decision Table contains your business logic — it evaluates conditions and returns decisions. A Lookup Table contains your business data — it stores values your rules need to reference.

For example: a Decision Table might say if country = US, apply fee structure, while a Lookup Table stores the actual fee values for each country. They work together: your Decision Table reads data from your Lookup Table to make smarter decisions.

Any logic that a business analyst would naturally write in a spreadsheet. Pricing rules, discount tiers, credit scoring bands, product eligibility, shipping cost calculations, tax rate lookups, fraud risk thresholds, SLA routing — if the logic involves mapping combinations of inputs to defined outputs, a Decision Table handles it cleanly. It's also the best starting point for business users who need to own and maintain rules without developer involvement.

Use a Decision Table when your logic is parallel — when you're evaluating many combinations of inputs against a flat set of rules and returning a result. Decision Tables are best for flat, coverage—based logic: here are all the scenarios, here are their outcomes.

Use a Decision Tree when your logic branches — when the path through the decision depends on the outcome of earlier conditions. Decision Trees shine for sequential, multi—level reasoning where one answer unlocks the next question.

Yes — the Decision Table editor is designed to feel exactly like the spreadsheet tools your team already uses. Click a cell to select it, use arrow keys to navigate, Tab to move across columns, Enter to confirm and move down. Select a range with Shift+Click, select entire rows by clicking row headers.

If you've used Excel or Google Sheets, you already know how to use it.

Yes. Any row can be deactivated — it stays in the table, stays visible, but is skipped entirely during evaluation. This is useful for staging new logic before it goes live, disabling seasonal rules without losing them, or keeping historical rows for reference. Reactivate with one click when you're ready.

You control this with the execution strategy. The default Standard strategy returns all matching rows in the order they appear in the table. First Match returns only the first matching row — useful when you want a single, prioritised result. Array returns all matches grouped into arrays. Evaluate All runs every row regardless of match and returns each one with a flag indicating whether it matched or not, giving you full visibility over the entire table's evaluation.

See our documentation on Execution Strategy for details.

Enable Debug Mode in the Test Bench and run your input — the table comes alive. Every condition cell turns green if it passed or red if it failed, and each cell shows the actual value the engine compared against your input. Matching rows are highlighted so you see at a glance exactly why a row fired or didn't. It's the fastest way to understand unexpected results without leaving the editor — you see the full evaluation, not just the final output.

See our documentation on Debug Mode for details.

Yes — every row supports time validation. Set a from and to date and time range on any row, and the engine will only evaluate that row within that window. Outside of it, the row is skipped entirely, as if it were inactive. It's the cleanest way to handle seasonal pricing, promotional rules, temporary overrides, or any logic that should only apply for a defined period — no manual activation needed, no risk of forgetting to turn it off.

See our documentation on Time Validation for details.

Valid Values let you restrict what can be entered in a cell to a predefined set of allowed values. There are three ways to define them: a simple array of values, a regex pattern, or a reference to a Lookup Table. Valid Values are most useful when a column has a fixed set of meaningful options — country codes, product categories, status values — and you want to prevent free-text mistakes.

See our documentation on Valid Values for details.

Just like in Excel or Google Sheets, the formula bar sits above the table and always shows the value and operator of the selected cell. You can edit directly in it — changes sync back to the cell in real time. It's especially useful for longer expressions or complex functions that are hard to read inside a small cell. The formula bar is resizable so you can expand it as needed.

Autofill works like it does in Excel. Select a cell or range, then drag the blue square that appears at the bottom-right corner in any direction — down, up, left, or right. If the source values form an arithmetic sequence (1, 2, 3 or 10, 20, 30), Autofill continues the pattern automatically. For non-numeric or irregular values, it cycles through the source values and repeats them across the target range.

Functions let you express computed logic inside cells — mathematical operations, string manipulation, date calculations, conditional expressions, and more. DecisionRules has a full library of built-in functions that can be nested and combined.

Writing functions is also where the AI Assistant comes in: select any cell in the Decision Table and ask the AI Assistant to generate a function expression for it. The assistant is aware of the cell's context — available input variables, the current operator, the table structure — so it generates correct expressions rather than generic code.

See the full Functions reference in our documentation.

Any rule type can call a Decision Table using the SOLVER function — Scripting Rules, other Decision Tables, and Flows... The most common pattern is using a Decision Table as a node inside a Flow, where it handles one layer of logic as part of a larger automated process. You can also call a Decision Table directly via the Rule Solver API as a standalone rule.

Yes. Any rule or Flow in your workspace can call the same Decision Table via its rule ID or alias. Using an alias is the recommended approach — you can configure the calling rule to always use the latest published version, so the moment you publish an updated table, every caller picks it up automatically. One publish, everything stays current.

Yes. Open the AI Assistant from the Rules List and describe the logic you need in language — a pricing table for three subscription tiers with monthly and annual billing or an eligibility rule based on age, income, and employment status. The assistant builds the input/output model, creates the columns, and populates rows based on your description. It can ask follow-up questions when your description is ambiguous.

The result is a working table you can run immediately or continue refining through the assistant.

Yes. Just describe what you're looking for — where do I set the execution strategy or how do I add a new column — and the assistant highlights the exact element in the interface. Useful when you're new to the platform or working in a part of the editor you don't visit often.

Learn more in our documentation .

Yes. Click on a cell and ask the assistant to write a function for it — the assistant sees the cell's context, including available input variables and the current operator, and generates a correct, ready-to-use expression. It can also explain what an existing function does, debug one that isn't returning the expected result, and combine multiple functions for more complex logic.

Learn more in our documentation .

Yes. Just ask — it knows your table's structure and can generate real-world inputs, inputs designed to match specific rows, inputs targeting edge cases or boundary conditions, or inputs that intentionally don't match any row to expose gaps in your coverage. You can also describe what you want: give me an input that matches row 3 or generate a case that hits the ELSE row.

Learn more in our documentation .

Yes. Ask it to summarise the rule and it reads your entire table and generates a plain-language description of the logic — what conditions it covers, what outputs it returns, and how the rows relate to each other. Useful for documentation, onboarding new teammates, or preparing a rule for a business review without requiring anyone to read the table itself.

Learn more in our documentation .

An AI Agent is a native rule type that uses a large language model to read, reason, and return structured data. You assign it a role, write a prompt that sets the context, define an output schema that controls exactly what comes back, and connect it to the model of your choice.

The result is always typed, always structured, and always ready to feed the next rule in your workspace: a Decision Table, a Flow, or another AI Agent.

Decision Tables match conditions against structured input and return a defined output. Scripting Rules compute and transform data using code. AI Agent does something neither can: it interprets. It reads unstructured input, understands context, and extracts meaning.

The most common pattern is to use all three together: AI Agent reads the raw input and produces structured data, a Decision Table evaluates that data, and a Scripting Rule handles any calculation on top.

The key principle: each AI Agent should do one job. Don't ask a single agent to read a document, score risk, summarize findings, and route the case: that's four jobs. Split them into focused agents, each doing one thing well.

One real pattern for Workers' Compensation Claims:

A medical report arrives, the AI Agent's only job is extraction, it reads the report and outputs structured fields: injury type, affected body part, estimated recovery weeks, work capability.

From there, the rules engine takes over with clean, typed data. A Decision Table routes by severity, another validates coverage, the next calculates the reserve amount.

Try this template.

No. They solve different problems. AI Agent is a rule type that processes production data at runtime: it reads unstructured input, reasons over it, and returns structured output inside your Decision Flows.

AI Assistant is a workspace helper that lives in the editor: it helps you build rules, generate test data, write functions, and understand existing logic. One runs your decisions. The other helps you build them.

Learn more about AI Assistant

No. AI Agent is schema-first, the output schema does most of the work. The prompt sets role and context in plain language; the schema controls what comes back. If you can describe the task in a sentence and name the fields you need, you have everything required to build an AI Agent.

Use an AI Agent when the task falls into one of three patterns.

First, extraction: turning unstructured input like contracts, reports, or emails into structured fields your rules can act on.

Second, routing and decisions: evaluating input and returning a score, a risk flag, or a routing outcome that doesn't reduce to a clean set of conditions.

Third, analysis and narrative: summarising complex data, writing a decision rationale, or producing a report, either mid-Flow or at the end once all other rules have run and their outputs are available.

Google Gemini, Google Vertex AI, Anthropic, OpenAI, and Microsoft Foundry. Connect any of them via the Connectors panel and assign them to individual AI Agents. New model providers are added regularly, check the Connectors panel for the current list.

See our documentation for the full setup guide.

Yes. Each AI Agent is connected to a specific model independently. One rule can run on Gemini, another on Claude, another on GPT-4, all within the same workspace.

This lets you match the model to the task: a fast, cheap model for high-volume extraction, a more capable one for complex reasoning.

You can connect your own API key or enterprise endpoint through the Connectors panel. DecisionRules doesn't require you to go through a proprietary model layer: you bring your own connection and your own agreement.

Your existing pricing, usage terms, and data processing agreements with the provider remain in effect.

You do. DecisionRules provides the rule framework, the schema engine, the versioning, and the Flow integration. The model connection is yours: your key, your provider, your contract.

DecisionRules never proxies your model calls through its own infrastructure.

Directly in the AI Agent editor. Add fields, set their type: string, number, boolean or automatic. Write an annotation that describes what the field contains and how it should be determined. The schema is what controls extraction quality. Precise, specific annotations consistently outperform vague ones. Think of each annotation as an instruction to a careful analyst, not a label on a column.

Very consistent for well-defined schemas with precise annotations. AI Agent is designed for typed extraction, the schema acts as a contract between your prompt and the model. That said, LLMs are probabilistic by nature. For maximum consistency, use specific field types, restrict values with enums where possible.

Yes. Define the allowed values in the field annotation, for example, Allowed values: litigation · arbitration · mediation · negotiation, and the model will only return one of those values. This is the most reliable way to ensure downstream rules receive predictable, matchable output.

What the model returns when it can't determine a value is entirely up to you, and you define that in the prompt. Null is a common choice because it's easy to check downstream. But depending on your use case, returning "N/A", "unknown", or a domain-specific fallback may be more meaningful.

Whatever you choose, be explicit about it in the prompt and stay consistent, your downstream Decision Tables need to know what to expect when a field couldn't be filled with confidence.

When caching is enabled, DecisionRules stores the result of each AI Agent call against a hash of the input. If the same input is received again within the cache window, the stored result is returned immediately: no model call, no token usage, no latency. The cache is per-rule and per-input. Change anything in the input and a fresh call is made.

Caching is available to try on the trial plan. For production use it must be included in your contract.

If you're unsure whether your plan covers it, check your subscription or reach out to our team via support.

Explainable AI adds a reasoning layer to every response. When enabled, each call returns a confidence score, a plain-language paragraph explaining how the output was reached, source fragments, the exact phrases from the input that drove each extracted value, and warnings for anything extracted with reduced certainty.

Turn it on when the rule's output will influence significant decisions, when you need an audit trail, or when you're still tuning the rule and want visibility into what the model is doing.

It's the model's own assessment of how reliably it could extract the complete output: a number between 0 and 1. A high score means most fields were explicitly stated in the input. A lower score means more values were inferred, estimated, or drawn from ambiguous phrasing.

Use it as a signal, not a guarantee, a 0.95 doesn't mean the output is correct, it means the model was confident. Pair it with warnings to get the full picture.

Yes. Source fragments are returned as structured output alongside the main fields, they're part of the response, not a separate debug log. Their primary value is in auditing: instead of reading the entire input document to understand why a decision was made, an auditor can read only the exact phrases the model extracted.

Explainable AI is available to try on the trial plan. For production use it must be included in your contract.

If you're unsure whether your plan covers it, check your subscription or reach out to our team via support.

Common document formats including PDF and others, check the documentation for the current list of supported types.

Use attachments for reference material that applies to every call: compliance policies, underwriting guidelines, product manuals, pricing rules, legal standards.

Attachments are configured at the rule level, the same document is available to every call that rule processes. If the reference material changes, update the attachment and publish a new version of the rule.

Input model fields are dynamic: they carry the data specific to each individual call, like a contract to review or a claim report to analyse. Attachments are static: they carry the reference context that applies to every call, like the underwriting guidelines the AI should reason against.

Three levers: schema precision, caching, and model selection. A precise, focused schema with clear annotations produces shorter, more reliable outputs than a vague prompt that leaves the model to decide what to return: shorter outputs mean fewer tokens. Caching eliminates model calls entirely for repeated inputs. Choosing a smaller, faster model for high-volume extraction tasks can reduce per-call cost significantly without sacrificing quality for well-defined schemas.

No. A cached response is returned by DecisionRules without making a call to the model provider. Your model's API is never called for a cached result, so it doesn't count against your quota, rate limits, or billing.

Yes, limits apply to both input size and attachment size and vary by model provider. Each provider sets its own context window, which caps the total amount of text the model can process in a single call. If your input or attachment exceeds the model's limit, the call will fail.

Check your model provider's documentation for current limits, and structure your inputs to stay well within them.

Yes, exactly the same. Every save is captured in Rule History and can be restored at any time. Versions are manual snapshots you create before significant changes: a prompt rewrite, a schema update, a model swap. You can roll back to any previous state in one click, and publish with the same confidence as any other rule in your workspace.

Yes. When you reference an AI Agent from a Flow, you can configure it to always use the latest published version, so a single publish propagates everywhere, or pin it to a specific version, so that Flow stays on a known state while you iterate.

Yes. Enable the Audit Logs on any AI Agent and every call is recorded: input, output, timestamp or execution time. Use it for compliance, debugging, or building a record of AI-assisted decisions. When Explainable AI is also enabled, the audit log captures the full reasoning output alongside the structured result.

See our documentation on Audit Logs configuration for details.

Everywhere in the app. Just click the AI Assistant button in the top-right corner.

Anything about the DecisionRules platform: how features work, where to find settings, how to set up Decision Flows, how to publish a version, and much more. You can also ask about your specific rule if you have one open.

No. Your rules and data are never used to train public AI models. The assistant reads your rule structure to give contextual answers, but that information stays within your session. See our Trust Center for details.

The assistant works across all rule types: Decision Tables, Scripting Rules, Decision Trees, and more. It reads the active rule's structure and provides contextual answers, generates test data, writes functions, and summarizes logic. It is also available on the Rules List for general platform questions and rule creation.

The AI Assistant is available on Lite Plan or higher and is included in the Free Trial. Check your plan details on the pricing page for specifics on feature availability.

Yes. When you ask something like "Where do I set the execution strategy?" or "How do I add a new column?", the assistant highlights the exact UI element you need to interact with, right in your browser.

es. Describe your business requirement in natural language, such as "if the loan amount is above 50,000 and the credit score is below 600, flag as high risk." The assistant will generate a Decision Table with the matching input model, output model, and conditions. The same works for Scripting Rules: describe the logic and the assistant produces a working script.

Yes. You can paste data from your existing Excel spreadsheets directly into the assistant chat. It reads the structure, identifies any embedded formulas, and recreates the logic as a clean Decision Table using native operators.

It works best with rules of up to around 100 conditions. For larger tables, we recommend a hybrid approach: let the assistant create the logic structure, then populate the data using the UI or Excel import.

The assistant generates a first draft that you always review before publishing. In our benchmarks, the AI-generated tables followed QA best practices, using native operators instead of complex formulas, which made the tables easier to manage and modify.

The assistant excels at medium-sized rules of medium complexity. For very large tables with hundreds of rows, we recommend a hybrid approach: let the assistant create the logic structure, then populate the data using the UI or Excel import/export.

From a controlled internal experiment where three groups (newbie, professional, expert) authored two rules manually and then with the AI Assistant. The average time reduction across all groups was approximately 60%. Read the full methodology.

It reads your Decision Table structure, including column names, data types, and conditions. Based on that, it generates input values that are realistic and relevant to the logic in your table.

Yes. You can say something like "Generate 10 random test cases" or "Create 5 inputs for the premium tier path." The assistant generates exactly what you ask for.

Yes. If a column expects a number, you get numbers. If it expects a string from a specific set of valid values, the assistant uses those values. It matches the structure of your table.

Yes. The assistant generates test inputs that you can run directly in the Decision Table editor's test panel. You see the results immediately and can verify that your logic works as expected.

Rule Tests let you save test cases into Suites for repeated use, for example as part of your CI/CD pipeline. The AI Assistant helps you generate those test cases faster. They complement each other well.

No. Your test data stays within your session. DecisionRules does not use your rules or data to train public AI models. See our Trust Center for full details.

Yes. The Function Builder is designed for function cells within Decision Tables. For Scripting Rules, you can use the Scripting Rules Architect, which can generate new scripts and edit existing ones. Describe the logic you need and the assistant produces a working script for you.

Yes. When you have a Decision Table open, you can ask the assistant to explain any function in any cell. It gives you a step-by-step breakdown in plain language, including how the inputs are used and what the expected output is.

Tell the assistant what is happening versus what you expected. It will help you debug the expression and suggest a fix. You can iterate back and forth until the function does what you need.

Mathematical operations (arithmetic, rounding, min/max), date calculations (adding days, comparing dates), string manipulations, conditional logic (if/then within a cell), and compound expressions that combine several of these together.

No. Describe what you need in plain language, like "apply a 15% discount if the baseTicketPrice is greater than 1000." The assistant generates the function expression in the correct syntax for you.

Yes. Paste an existing function into the chat and tell the assistant what you want to change. For example: "Add a minimum fee of 50 to this calculation." It will return the updated function.

A typical summary covers the input model (what data the rule expects), the output model (what it returns), the condition structure (how the logic is evaluated), and a plain-language explanation, including key decision paths and edge cases.

Yes. You can ask broad questions like "What does this table do?" for a full summary, or specific ones like "Explain how row 7 is evaluated" or "What happens when the credit score is below 600?" to get targeted explanations.

The assistant reads your actual table structure, conditions, and functions. The summary is based on what is in the table, not on assumptions. That said, you should always verify the summary against the table, especially for critical rules.

The summaries provide a solid starting point for audit documentation. They explain the logic in plain language and capture the key structures. For formal audit reports, you may want to review and adjust the wording to match your organization's documentation standards.

Yes. You can ask broad questions like 'What does this rule do?' for a full summary, or specific ones like 'Explain how row 7 is evaluated' or 'What happens when the credit score is below 600?' to get targeted explanations.

Absolutely. The AI assistant is designed to bridge the gap between technical rule builders and business decision-makers. It translates complex table logic into plain, natural language, making it easy for compliance teams, auditors, and project managers to review and understand exactly what a rule does without any technical background.

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.

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.

Decision Flow works best for real-time business decisions where multiple steps need to happen in sequence. Typical examples include pricing calculations, approval workflows, eligibility checks, onboarding flows, fraud screening, routing logic, or combining multiple partial decisions into one final result.

If your logic involves first evaluate this, then call another rule, then enrich the data, then produce a final response — Decision Flow is the right fit.

Decision Flow is optimized for fast, real-time execution. It handles most business decision workloads where the evaluation finishes within the allowed execution time.

Integration Flow was built for long-running processes such as large database queries, bulk processing, or slow external integrations that may exceed normal execution limits.

The two complement each other:

Decision Flow handles immediate decisions.

Integration Flow handles large-scale or long-running processing.

Yes. If your Decision Flow grows beyond the execution limits — for example due to large datasets or long-running API calls — you can convert it into an Integration Flow without losing your work.

This allows teams to start simple and scale only when needed.

Decision Flow can orchestrate all major rule types across your workspace, including Decision Tables, Decision Trees, Scripting Rules, and more. Each node in the flow performs one responsibility, while the Flow coordinates the entire execution process.

Yes. Decision Flow supports REST API calls directly inside the flow execution. This allows you to enrich decisions with external systems, retrieve additional data, or trigger downstream services as part of the decision process.

Because Decision Flow is optimized for real-time execution, external calls should be tested to ensure they complete within the execution time limits.

Plan for failure paths from the start. You can add fallback branches, validate required inputs early, and define alternative paths for missing data or failed API calls directly inside the Flow.

But when something still goes wrong, Decision Flow includes Inspect Mode — a visual execution view that shows exactly what happened inside each node during runtime. For every node, you can see:

This makes debugging dramatically easier than tracing hidden backend workflows or digging through application logs.

If execution takes too long, the flow may time out. This usually happens with very large bulk inputs, complex processing chains, slow API responses, or large database operations.

In these cases, the recommended solution is moving the workload into an Integration Flow.