Frequently Asked Questions
Business Rules
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, 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, 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.
Integration
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.
Through the native MCP integration, AI tools can access predefined templates, reusable components, documentation, Academy resources, and structured content, and can create, update, test, and execute rules in an authenticated space, with every change reviewed before it goes live.
Yes. Any application capable of making standard HTTP requests can communicate with the Management API.
Yes. The Management API is designed to support automation workflows, making it easy to integrate rule management into deployment pipelines, scripts, and internal tools.
No. You connect with the DecisionRules account you already have, and you pick which space the assistant works in during setup.
Claude, ChatGPT, Codex have native connector support. Anything else that speaks MCP can connect through Smithery.
Deployment
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.
Our average customer can integrate DecisionRules into their system easily within a few hours.
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.
Public Cloud, Private Managed Cloud, or self-hosted on Docker and Kubernetes, including on-premise.
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.
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:
General
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.
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.
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.
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:
- Rule inventory: Document all existing rules, their dependencies, and business owners.
- Platform selection: Choose a modern platform that supports your rule complexity and compliance needs.
- Rule conversion: Translate rules to the new format—some platforms like DecisionRules offer automated migration tools.
- Parallel testing: Run both systems simultaneously to validate identical outcomes before cutover.
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:
- Data Extraction: It reads unstructured inputs—like contracts, medical reports, or emails—and instantly extracts key information into a structured, typed JSON format. This clean data is then ready to be processed by deterministic rules downstream.
- Intelligent Routing & Scoring: It evaluates cases that require context and language comprehension, such as assessing narrative risk signals, categorizing support tickets, or flagging anomalies that don't fit into neat conditional boxes.
- Analysis & Narrative Generation: It can condense complex data into plain-language summaries or write out clear rationales explaining the "why" behind a specific decision mid-Flow.
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.
A rule engine separates logistics decision logic from hardcoded WMS, ERP, or TMS workflows. It allows teams to manage carrier rules, pricing logic, route conditions, segmentation, and operational constraints in one dedicated decision layer.
Yes. Existing systems can send shipment or planning data to DecisionRules through REST API and receive calculated outputs such as eligible carriers, costs, ranked options, validation responses, or standardized operational metrics.
Common examples include carrier eligibility, shipment segmentation, route cost calculation, carrier price calculation, strategic carrier selection, planning simulations, invoice validation support, and profitability analysis.
The core decision logic is rule-based, deterministic, and auditable. That is important for carrier costs, pricing, routing constraints, and invoice validation. AI can support future optimization use cases, but the reliable foundation is a transparent decision layer.
No. DecisionRules works alongside existing systems. WMS, ERP, TMS, planning tools, dashboards, Excel datasets, and partner systems can call the decision layer and receive standardized outputs.
Ancient Egyptian administration used structured logic to classify land, assign obligations, and apply taxation rules consistently. DecisionRules follows the same basic principle today, but makes the logic explicit, automated, and executable through modern systems.
The Wilbour Papyrus shows how land type, holder, area, and productivity context influenced tax obligations. In DecisionRules, similar inputs can be transformed into decision tables that automatically produce consistent outputs.
Yes, the idea behind business rules is not new. Societies have always needed ways to apply decisions consistently at scale. DecisionRules brings this timeless concept into modern digital workflows.
Decision update propagation describes how a rule change spreads through a system. In Ancient Egypt, rule changes moved through officials and scribes. In DecisionRules, updated logic can be deployed instantly and used across connected systems via APIs.
When rules are hidden in code, every change may require developer time and deployment cycles. With DecisionRules, business users can manage decision logic directly, test changes, and keep systems aligned more easily.
Explainable AI surfaces the model's reasoning alongside every result as structured data. Instead of returning just an answer, it attaches the confidence, reasoning, source evidence, and any warnings behind the decision, so your team can read, audit, and act on it.
Every response carries four pieces of structured information: a confidence score, the reasoning behind the conclusion, the source evidence the model relied on, and any low-confidence warnings. Together they show what the model concluded, how certain it was, where it found each value, and where it made a judgment call.
It is a built-in capability of the DecisionRules AI Agent, activated with a single toggle in the rule designer. There is no custom prompting, no extra configuration, and no separate tool to connect.
No. Once enabled, the explanation object is generated automatically at execution time and returned alongside your regular output fields. You do not configure, define, or prompt for it.
It matters most where a wrong answer is expensive and a human still has to sign off: lending, insurance, procurement, KYC, compliance, and contract review. In each, a different field does the work, from warnings flagging uncertainty to the reason field writing the audit trail.
Yes. Compliance and operations teams can read and validate the model's reasoning directly, checking whether outputs match policy intent without needing engineering to interpret them.
A normal output gives you a result with no visible reasoning. With Explainable AI, a score comes with the reason behind it, a flag becomes something a reviewer can act on in seconds, and an audit request stops being a scramble. It changes the decision, not just the output.
An AI Agent is a native rule type that delegates decision logic to a large language model. Instead of rows of conditions and outcomes, you describe what you want the model to do in plain language and define the output structure. Every time the rule runs, it reasons over the input and returns a typed, structured JSON response that your downstream rules and flows can act on immediately.
Let the input guide the choice. Structured, explicit values suit a Decision Table or Tree, which are faster and easier to audit. Meaning that has to be interpreted, like a contract clause, a clinical note, or a free-text complaint, is where an AI Agent fits. The AI Agent does not compete with deterministic rules, it covers the cases they were never meant to handle.
Most use cases map to one of four patterns: a Decision Maker that produces a score, classification, or routing outcome; a Policy Validator that checks data against a standard and flags failures; a Report Writer that turns complex input into a clear summary; and a Deep Analyzer that extracts structured fields from a document or record. If a use case spans more than one, the best practice is to split it into focused agents.
The output is typed JSON against a defined schema, not free text, so downstream logic can consume it directly. With Explainable AI enabled, every response also carries a confidence score, reasoning, sources, and warnings, and low-confidence outputs can be routed to human review. Response caching returns a stored result when the same input reaches a rule twice in a short window.
It extends deterministic rules rather than replacing them. A common pattern has an AI Agent extract structured fields from a document, a Decision Table apply explicit business logic, and a Decision Flow orchestrate the sequence and route on confidence. Because the model runs inside the same platform as your deterministic logic, every component stays governed, versioned, and auditable, keeping AI decisions inside your governance perimeter.
The AI Assistant is a context-aware partner built directly into the DecisionRules workspace. It lets you describe a rule in plain language and turns it into a working Decision Table, functions, and test data, all inside one window. It removes the friction around building a rule, namely translating a policy into a structured table, writing the right function, and inventing test data to prove it works.
You outline a policy in plain language or paste in a description of the logic, and the Assistant interprets it and builds a structurally sound Decision Table or script layout in your active window. There is no engineer handoff to translate intent into rows. Internal benchmarks across three analyst experience levels show an average 60% reduction in rule authoring time and a 3x increase in daily productivity for risk and business analysts.
Yes. The Function Builder lets you select a cell or node and ask for the expression instead of hunting through documentation. It reads the surrounding context, proposes a clean formula, and can explain logic that is already there, including multi-conditional blocks, date math, and array operations. It works like a pair-programmer that already knows your rule.
The Assistant reads your input and output schemas directly and builds the test matrices for you, so you do not hand-write mock JSON payloads. You can generate random datasets to stress-test execution limits, coverage for logic paths nobody has exercised yet, or the exact combination that makes a rule fail, all without typing a single payload.
The AI Assistant runs on Google Gemini under enterprise privacy terms, and is available on cloud plans out of the box. Your rules context and operational payloads stay isolated and never train public models. For stricter data governance, a self-managed deployment lets teams connect their own credentials and keep all AI interactions within their own infrastructure.
Decision Tables, Decision Trees, Scripting Rules, and the AI Agent rule type, composed into Decision Flows.
A stateless, deterministic decision automation platform. It runs your business rules over a REST API, versioned and auditable, so the same input always returns the same decision.
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 hear this constantly. Legacy BRMS platforms were designed for a different era, with six-figure licensing, months-long implementations, and heavy IT dependency. DecisionRules gives you the same rules management capabilities with a modern, lightweight architecture. You deploy in days, not months, and your business teams can manage rules directly without filing IT tickets.
Every rule in DecisionRules is fully versioned with snapshots. You can test a new version of a pathway or fee schedule in a staging environment, then promote it to production when you're ready. If something goes wrong, you roll back to the previous version instantly. The full version history is maintained as part of your audit trail. Before you promote a version, run it against a saved suite of test cases and confirm the outcomes are exactly what you expect, so nothing reaches production untested.
That's a core pattern for DecisionRules. You organize rules into separate spaces with their own roles and permissions, so each payer, TPA, or employer group has its own isolated rule set. A shared rule, like a grouper or a fee calculation, is defined once and reused across every tenant. When one payer renegotiates, you update their rules without touching anyone else's.
Stage the change in advance and let it go live automatically. Every rule, and every row inside a Decision Table, can carry a validity period, so a new guideline or plan-year fee schedule activates at the exact effective date and time. No midnight deployment, no manual switch. The previous version stays in your audit trail.
It's the most common starting point we see. Paste an existing SQL procedure or business rule into the AI Assistant and it drafts the matching Decision Table for you to review, including the input-output model, conditions, and outcomes. For larger migrations from legacy engines, Professional Services are available to convert your first rule sets and train your team.
It's the most common starting point we see. Paste an existing SQL procedure or business rule into the AI Assistant and it drafts the matching Decision Table for you to review, including the input-output model, conditions, and outcomes. For larger migrations from legacy engines, Professional Services are available to convert your first rule sets and train your team.
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.
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.
A medium-complexity decision table (20 rows) or decision tree averages 8.1–8.2 milliseconds end-to-end at a sustained 5,243 solves/s, measured client-side including network round-trip, with a median of 6.8–6.9 ms and p99 of 18–19 ms. Average latency stays below 10 ms up to approximately 8,900 solves per second.
Performance
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.
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.
To see what a new version would do before it does it. The current version keeps serving production while the candidate runs on the same applications and logs what it would have decided, without acting on it. You set it up by calling the rule twice, once pinned to each version, sending the same input to both. The candidate's result is logged, not used. When it behaves the way you expected, you promote it.
It stays. Editing produces a new version rather than overwriting the previous one, and the old version keeps its own audit logs. That is what lets you compare against it, and what lets you answer a question about a decision made under a policy you have since replaced.
Either. The comparison picker takes any rule. The only requirement is that the field you are looking at exists on both sides, since a chart needs something to draw. Comparing versions of one rule is the cleanest case because everything else is held constant.
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.
In our tests, the replica ceiling, not the engine. Both capped and elastic configurations behaved identically up to 100 concurrent clients. Beyond that, the elastic deployment continued scaling while the capped one plateaued at roughly 9,800 solves/s.
Two k6 load tests against DecisionRules on Kubernetes, with load generators running in the same region as the cluster. Every call was content-validated, not just checked for HTTP 200. All figures are client-observed round-trip times, so they include network transit, not just server-side execution.
For decision tables, latency rises from 3ms at 500 req/s to 10ms at 100k req/s under fixed workload. However, this can be avoided with scaling.
Zero. All requests passed both HTTP 200 and content validation.
A multi-rule flow (up to 10 rules) averages no more than 5.5 ms, depending on whether rules are run in parallel or in sequence.
It’s faster in a flow — a flow that calls 5 parallel small decisions is only 0.1 ms slower than a single decision. Most of the execution time is already spent in orchestration rather than in evaluation.
A medium decision table (around 20 rows) or decision tree is processed in under 3 milliseconds at 500 requests per second — including network round trip.
We measured over 106,000 decisions per second with 600 concurrent virtual users.
License
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.
Security
DecisionRules and our processes are compliant with ISO 270001 certification.
No. Your rules and data are never used to train AI models.
DecisionRules and our processes are compliant with ISO 270001 certification.
DecisionRules is a secure system. All connections are encrypted, and your data is also protected by encryption.
Management API keys are generated and managed individually within each Space.
Yes. Create separate API keys for different integrations, applications, or environments to improve security and simplify key management.
Users with the appropriate Space permissions can create, rename, or delete Management API keys.
Access is scoped to the space you choose, every change is versioned and reversible, and nothing publishes without you.
Onboarding
No. Anyone with Excel knowledge can use DecisionRules.
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.
Support
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.
No. Turn on logging for a rule and Statistics reads the logs it produces. The Data Dictionary discovers your fields from the log data itself, so there is no schema to declare and nothing to keep in sync.
Yes. The BI API is read-only, and there is a native Power BI connector. Your BI tool reads the same audit logs the Statistics page reads, so there is one source of truth and no copies to drift.
Yes, we offer our customers global support in 5x8, 24x7 modes, or individual times. You can easily contact support through our Support Portal.
Getting Started with Lookup Table
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.
Importing and Exporting Data
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.
Using Lookup Tables in Rules
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.
Versioning and Collaboration
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.
Best Practices
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.
Move to Integration Flow when your process stops behaving like a real-time decision and starts behaving like backend processing infrastructure.
Typical signals include:
- large bulk operations,
- slow external APIs,
- database-heavy processing,
- synchronization workflows,
- or execution chains that risk timing out in real-time mode.
Use Decision Flow for immediate decisions.
Use Integration Flow for long-running orchestration.
Keep orchestration readable and modular. Separate retrieval, transformation, evaluation, and persistence into clearly defined stages instead of mixing everything together in one massive workflow.
Well-structured Integration Flows are easier to debug, safer to modify, and much easier for teams to understand over time.
Usually no. As a best practice, keep business decision logic inside reusable rules like Decision Tables, Decision Trees, or Decision Flows.
Let Integration Flow focus on orchestration:
- retrieving data,
- coordinating systems,
- handling processing steps,
- and managing execution flow.
This keeps your architecture cleaner and your logic reusable across both real-time and long-running workloads.
While Audit Logs are essential for production environments to maintain compliance and debug issues, you might choose to disable them for high-volume, non-critical testing environments to optimize storage. A great practice is to enable them globally for all production workspaces and use shorter retention windows for staging areas.
Debug Data are incredibly valuable during development, onboarding, or heavy troubleshooting cycles because they pinpoint logic flaws instantly. However, because they store a detailed breakdown of every single condition, they consume more storage than standard Audit Logs.
We recommend enabling Debug Data in staging environments or activating them temporarily in production only when diagnosing a specific issue.
We recommend utilizing the server-side filters provided by the BI API. By filtering by specific date ranges, status codes, or rule IDs directly in your API request, you drastically reduce the payload size, making your dashboard refreshes significantly faster.
When paired with our AI Agent rule type, Audit Logs automatically capture the advanced outputs of Explainable AI. This means your logs will not just show a raw text output. Instead, they store the exact confidence score, the warning flags, and the verbatim source fragments used by the AI model to make its decision, creating a highly transparent audit trail for automated AI decisions.
Learn more about AI Agent.
No, you should always keep them separate. Use your Rule Solver API keys strictly for running live applications, and issue a dedicated BI API Key to your data team. This isolation ensures optimal security and keeps analytical workloads separate from operational systems.
Start with your outputs. The decision itself, the score, the tier, the routing outcome. A frequency distribution on your main output field is the fastest way to see whether your rule behaves the way the business believes it does, and it very often surfaces a surprise in the first minute. Then look at inputs to understand who you are actually receiving, and metadata to check performance and errors.
Compare. Put the new version and the previous one side by side, or keep one rule and compare last week against this week. A shift in the distribution of outcomes right after a publish is exactly the signal you want to catch on day one rather than at quarter end.
Narrow your range. The Data Dictionary is built from a sample of recent logs, and the charts sample once the matching set grows past ten thousand records, which keeps the page fast on large workspaces. That sample is meant to be representative, and for exploring trends it is exactly right. When you need precision on a specific model version or a specific incident, tighten the date range or filter by rule version, and for exact figures on the full dataset use the Business Intelligence API.
Trust it, then verify it. That is what the Raw Data Table is for. When a distribution shows something unexpected, drop into the underlying logs and read the actual records. The path from an aggregate to the individual execution that caused it is one click, which is the whole point of having statistics inside the rule engine instead of three systems away.
Create a new version for changes that deserve their own testing and release checkpoint, for example a new pricing strategy, a compliance update, a major restructuring, or any change that should be promoted independently.
For production rules, create a new version and make the change there. Keeping development in a Pending version protects the currently published behavior and gives the team a clear review and testing step.
Use explicit versions when an integration must remain pinned to known behavior. Test the Pending version, compare it with the currently used version, publish it after approval, and promote it between environments through the Management API or a CI/CD pipeline.
Keep versions that represent meaningful releases, audit points, or rollback candidates. Remove only versions that are no longer useful. Deleting a version does not renumber the remaining versions.
Generate separate Management API keys for each application, service, or deployment pipeline. This improves security, simplifies key rotation, and allows individual integrations to be managed independently.
Use the Management API whenever business rule administration becomes repetitive. Automating updates, versioning, migrations, and backups improves consistency while reducing manual effort across your development workflow.
No, and that is by design. Logs are generated and stored per rule, so enable them where the trail matters, like production rules under compliance or ones you are actively debugging.
Because one keeps the record and the other sounds the alarm, and you want both. Webhooks push you the moment something happens, so your systems react without anyone watching. Event Logs hold the full history in one place, so when a Webhook fires you can open the log and see the complete context.
When you compare two versions of the same rule. Comparing two unrelated rules works too, but nearly everything reads as different, so it is rarely helpful.
Make it your final review step. Open the new version against the current live one, step through each difference, check the statistics for a quick count, and confirm every change is intentional. It turns "I think this is right" into "I can see exactly what I changed."
Create Teams and Departments that reflect how your company already operates. Familiar structures simplify onboarding, improve administration, and make it easier to scale as your organization grows.
Configure branding, authentication, and AI Provider settings at the Organization level to ensure a consistent experience across every workspace while reducing administrative effort.
Use the same logo and visual identity your teams already recognize from other internal systems. A consistent experience helps DecisionRules feel like part of your existing technology environment rather than a disconnected tool.
Choose a clear horizontal logo and brand colors that remain readable within the DecisionRules interface. Your branding should make the environment recognizable without reducing usability or visual clarity.
Implementation, Migration & Technical Setup
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.
Product Capabilities, Comparison & Business Value
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.
How does it work?
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.
Key Features
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.
Alternatives
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.
Implementation & Technical Success
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.
Pricing & Cost Optimization
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.
Compliance & Quality Assurance
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.
Getting Started with
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.
Using Decision Trees in Rules
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.
Getting Started with Tests
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.
Creating tests
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.
Running Tests
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.
Visualizing test results and repairing rules
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.
Getting Started with Templates
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.
Importing Templates
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.
Template Library
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.
Getting Started with Decision Table
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.
Working with Decision Table
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.
Using Decision Tables in Rules
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.
Decision Table & AI Assistant
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.
Getting Started with AI Agent
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.
Models and Connectors
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.
Output Schema and Reliability
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.
Caching & Explainability
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.
Attachments
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.
Cost and Performance
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.
Versioning and Governance
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.
Getting Started
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.
Anywhere the AI Assistant panel supports attachments for the selected model.
Yes, each attached file can be up to 10 MB.
On the Rules List page, in the AI Assistant panel.
The Templates Helper is available on the Rules List page in the AI Assistant panel. Describe your business problem, and the Assistant recommends the most relevant templates for your use case.
Simply describe your business problem in plain language. You don't need to know template names or technical keywords—the AI Assistant finds matching templates based on your request.
You'll receive the most relevant templates for your use case, each with a short description to help you choose the best starting point.
The AI Assistant supports PDF, TXT, MD, CSV, XLSX, DOCX, XML, and selected IBM ODM file formats. Each file must be up to 10 MB. Availability of file attachments depends on the AI model selected in the Assistant.
File attachments are available in the right-hand AI Assistant panel, on any page where the selected AI model supports attachments. This includes the Rules List and Decision Table Detail, where the Assistant can use the attached document to draft new rules or generate test data.
File Import is part of the AI Assistant. Any user with access to the Assistant in your workspace can attach supported files.
Audit Logs can be toggled on or off directly within the settings of your individual rules. For production environments, keeping Audit Logs active is highly recommended to guarantee complete operational transparency and full accountability.
Audit Logs act as your business record because they save the input payload, output payload, and core metadata. Debug Data go much deeper by capturing the internal mechanics of the execution. It records the evaluation of individual cells, showing exactly why a specific row matched or why a branch failed.
Audit Logs are a native, enterprise-grade tracking feature that records every single execution within your workspace. Whenever an application calls a Decision Table, Decision Tree, Scripting Rule, or Flow via our API, the engine captures the exact timestamp, the rule version used, the raw input data, and the final output returned. It serves as your permanent, tamper-proof system of record.
The BI API Key is a specialized credential designed exclusively for Business Intelligence and data analytics. Unlike standard API keys used to execute rules, the BI API Key gives your analytics tools secure, read-only access to retrieve historical audit logs and execution metrics from your workspace.
No. The BI API Key enforces a strict read-only policy at the engine level. It cannot add, edit, or delete rules, tables, or flows. It is purely an extraction tool for your data analysts.
You can retrieve complete execution logs, including input payloads, output results, execution durations, timestamps, specific rule IDs, versions, and solver strategies. This provides all the raw material needed to calculate system performance and business outcomes.
You can create your key inside the DecisionRules portal by navigating to Space and selecting API Keys. From there click the Add API Key button and choose Business Intelligence from the key types to generate a token.
Statistics turns your Audit Logs into visual insight. Instead of reading executions one by one, you select a rule, a date range, and a field, and the page shows you how that field behaves across every matching execution: how values are distributed, how they change over time, and which individual logs sit behind the result. It is built into the workspace, so there is nothing to set up and nothing to export first.
Audit Logs enabled on the rule you want to analyze. That is the whole prerequisite. Statistics reads the logs your rules already produce, so any rule that has been logging has data ready to explore. The rule picker even marks it for you: a green dot means logs exist for your selected date range, an orange dot means there is nothing to analyze in that window yet.
It is the list of everything you can analyze. DecisionRules reads your Audit Logs and organizes the fields it finds into three scopes: Input, the data sent to the rule, Output, the data the rule returned, and Metadata, the technical detail around the execution such as rule name, version, status, etc. Search for a field, click it, and the statistics load.
Business questions and operational ones, from the same place. What share of applications get approved? Which customer segment dominates? How did the average quoted price move after last week's pricing change? Are error rates climbing? How long does this rule take at peak hours? If the value passed through the rule, it is available.
No. Picking a rule, a date range, and a field is the entire workflow. The charts are generated for you and the summary metrics adapt to the field you chose automatically.
Invite both new and existing DecisionRules users directly into your workspace. Once they accept the invitation, they can immediately begin collaborating based on their assigned role.
Yes. Secure Collaboration allows authorized users to work together in the same shared workspace, ensuring everyone has access to the latest version of your business logic.
The Management API provides programmatic access to DecisionRules resources, enabling developers to automate rule management and integrate DecisionRules with external applications.
Management API primarily supports the lifecycle of business rules, including creating, updating, versioning, publishing, organizing, importing, exporting, and maintaining decision assets. New capabilities continue to be added as the platform evolves.
Management API uses Bearer token authentication. Generate a dedicated Management API key within your Space and include it in the Authorization header of your requests.
Green is your rule, the one you have open. Blue is the version you compare against. Yellow means the row, column, or cell lives in both but changed. Anything with no color is identical. Learn it once and it works the same across tables and trees.
A quick tally of the differences, counted separately for rows and columns. For each you see how many stayed the same and how many changed, split by colour.
Same type only. Tables to Tables, Trees to Trees, Scripts to Scripts. That keeps the comparison meaningful, since a grid and a code file have nothing to line up against each other.
It puts two rules side by side and colours every difference between them. It answers one question fast: what actually changed? It shines when you compare two versions of the same rule, like your live version against the new one you are preparing.
No. You connect with the DecisionRules account you already have and choose which Space the assistant works in during setup.
Yes. The Space must have a Management API Key configured. Apart from that, the Space can be empty and your first request can create something in it.
The DecisionRules MCP Server is the connection between your AI client and your DecisionRules Space. Once connected, your assistant can create rules, explain them, generate test data, run them against real input, manage versions and tags, and trace dependencies.
Yes. The optional Distribution server serves DecisionRules documentation, templates, and reusable functions into your conversation with no login required. It never touches your Space.
Learn more: related documentation
Model Context Protocol is a shared standard that lets an AI client connect directly to a tool and take actions in it, instead of reading documentation and guessing. It is supported natively by ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and others.
No. Logo and color customization are independent. You can configure either one separately or combine them for a more complete branded experience.
White Labeling allows you to customize the visual identity of your DecisionRules environment with your own company logo and brand colors.
No. White Labeling changes the visual identity of your environment while keeping the underlying DecisionRules functionality and workflows unchanged.
You need DecisionRules App 1.26.1 or later and AI Engine 1.2.0 or later. Your user account must have permission to use the AI Assistant and edit the rule. The rule must not be locked.
Be specific about the change and the expected outcome. Focus on what should change or how it must behave instead of asking for a full rewrite.
How It Works
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.
No. The Assistant rewrites your request into a focused search query.
Yes. Describe your business problem in plain language, and the AI Assistant rewrites your request into a focused template search to find the most relevant matches.
You'll still receive the closest matching templates, so you can start from an existing structure instead of building everything from scratch.
Yes. Once you've selected a template, you can use it as the foundation for a new rule instead of starting with a blank page.
The AI Assistant analyzes your request, rewrites it into a focused search query, and recommends the templates that best match your described business problem.
Yes. Attach a policy, specification, or requirements document, describe the logic you need, and the AI Assistant drafts a Decision Table from the uploaded content. The output is a structured starting point that you review and refine, not a finished rule.
Yes. The Assistant receives both in a single request. You describe what you want, and the Assistant uses the attached document as source material for that request.
Yes. One uploaded document can serve as context across several requests. You can draft a Decision Table from one part, generate test data based on another, and ask clarifying follow-up questions, all without re-uploading.
Not every model supports attachments. The AI Assistant lets you pick from several models, and file attachment is available with those that support it. The model selector shows which are compatible.
Yes. The AI Assistant supports IBM ODM .brl, .dta, .rfl, and .var files as attachments. It uses them as context to understand your existing rule definitions and help you recreate equivalent rules in DecisionRules.
Each entry securely logs the unique execution ID, the rule ID, the specific version, the timestamp of the request, the execution duration in milliseconds, the final status (success or error), and the complete JSON structures for both the input request and the engine's output response.
Yes, this is one of its primary use cases. If a client application receives an unexpected response or an error, you can locate that exact execution in the Audit Logs panel. Inspecting the payload allows you to view the precise values passed to the engine, helping you replicate and fix the issue inside the rule's Test Bench instantly.
Three, and they work together. Frequency Distribution counts how often each unique value appears, which shows you the composition of your decisions. Time Series groups executions into intervals and plots a metric across them, which shows you movement and trends. Raw Data Table lists the individual Audit Logs behind the analysis, which lets you verify anything you see in the charts.
Three headline numbers, chosen automatically based on the type of field you selected. Numbers give you minimum, maximum, and average. Booleans give you true count, false count, and true rate. Dates give you earliest, latest, and count. Strings give you unique values, most common, and count. Objects and arrays report how many values are filled and how large they typically are.
Yes. Enable the comparison switch, select a second rule, and both are visualized side by side. You can give the secondary rule its own date range, which makes period-over-period analysis just as easy as rule-over-rule. If the selected field only exists in one of the two rules, the page shows the primary rule alone rather than guessing.
Relative or absolute, the same options you already use on the Audit Logs page. The selection is shared between both tabs, so changing it in one applies it to the other. Every chart and every calculation reflects the period you picked.
Yes. The Data Dictionary looks inside objects and arrays and surfaces the fields it finds within them, so an array of customers gives you access to customer ID, name, or status directly. For bulk-style inputs, statistics can count values from each item in the array rather than treating the whole array as a single value, which is what you want when a single execution carries a batch of records.
Types are detected from your actual audit data rather than declared in advance, so they reflect what is really in the logs. Mixed means the same field appeared with different types across records. Unknown means the value was missing, empty, or could not be determined confidently. Both are usually worth a look: they often point at a data quality issue upstream that is easier to fix once you can see it.
Rules Creation with AI
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.
Quality and Accuracy
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.
Generating Test Data
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.
Testing Workflow
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.
Understanding and Debugging
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.
Generating Functions
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.
How Summaries Work
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.
Use Cases
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.
Getting Started with Scripting Rule
A Scripting Rule is a native rule type that runs JavaScript inside a sandboxed environment built directly into DecisionRules. You write logic in code as calculations, transformations, conditionals, loops and the engine executes it at runtime like any other rule.
It has the same versioning, testing, and Flow integration as any other rule, but gives you the full flexibility of code when you need it.
Use a Scripting Rule when the logic is fundamentally computational rather than conditional. The clearest signals: you need to reshape or transform complex nested data structures, you need multi-step calculations where intermediate values feed into each other, or you need native JavaScript capabilities like custom sorting or deduplication.
If your problem is "evaluate conditions and return an output," that's a Decision Table. If your problem is "compute and transform data," that's a Scripting Rule.
Scripting Rule requires JavaScript — but the AI Assistant changes the equation. Describe the calculation or transformation you need in plain language, and the assistant generates the script for you.
Not sure if it's right? Ask the assistant to generate test inputs that should return a specific output, run them in the Test Bench, and check the result yourself. No developer required to write it, test it, or validate it.
Working with Scripting Rule
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.
Using Scripting Rules in Flows
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.
Getting Started with Decision Flow
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.
Using Decision Flow
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:
- the output it produced,
- and the data used during its evaluation.
This makes debugging dramatically easier than tracing hidden backend workflows or digging through application logs.
Execution and Performance
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.
Getting Started with Integration Flow
Integration Flow is a visual orchestration engine designed for long-running and large-scale processes. It allows you to connect rules, APIs, databases, and data transformations into one executable backend workflow that runs asynchronously in the background.
It was built for workloads that exceed the practical limits of real-time execution.
Decision Flow is optimized for immediate, real-time decisions — typically one request in and one response out.
Integration Flow is optimized for processes that take longer to complete. Instead of prioritizing instant responses, it focuses on reliable execution of larger workflows running in the background.
The two are complementary rather than competing.
Execution and Monitoring
Integration Flow was designed specifically for long-running workloads. Unlike real-time execution flows that risk timing out after a short execution window, Integration Flow runs in the background and can continue processing for up to 24 hours if needed.
This makes it suitable for:
- large database operations,
- bulk record processing,
- slow external APIs,
- synchronization jobs,
- migrations,
- and other backend-heavy workflows that simply cannot finish reliably in real time.
Traditional real-time orchestration expects an immediate response. That works well for frontend decisions and lightweight processing, but complex operations can quickly run into timeout limitations.
Integration Flow uses background execution instead. The process continues independently of the original request, allowing complex workflows to finish properly even when they involve large datasets or slow external systems.
Using Integration Flow
Yes. Integration Flow is specifically suited for database-heavy workloads such as retrieving large result sets, processing records sequentially, synchronizing systems, or updating external data sources.
This makes it ideal for backend operational processes that would be difficult inside real-time execution flows.
Yes. Integration Flow supports REST API integrations directly inside the Flow. Because execution runs in the background, it is much better suited for slow or complex external integrations than real-time orchestration.
Yes — this is one of its primary use cases. Integration Flow was designed specifically for high-volume and large-scale processing where many records, requests, or operations need to be executed as part of one workflow.
AI capabilities
A native rule type that reads documents, narratives, and signals and returns structured, typed output with explainable reasoning. It is distinct from the AI Assistant.
No. It builds and edits both Decision Tables and Scripting Rules, generates functions and test data, summarizes rules, recommends templates, and answers questions from the docs and Academy.
Around 60% less authoring time and up to 3x daily productivity, measured in a controlled benchmark.
Yes, for both the AI Assistant and the AI Agent: Gemini, OpenAI, Anthropic, Vertex AI, or Microsoft Foundry.
DecisionRules uses AI to help users create and maintain business rules. The AI Assistant can transform natural language into Decision Tables, generate functions and test data, explain existing business logic, summarize complex rules, and answer product questions using the DecisionRules documentation. Once created, business rules are executed by the DecisionRules engine, where they remain versioned, auditable, and deterministic, ensuring the same input always produces the same decision.
Advanced Features
The Assistant works best with documents that describe decision logic clearly: underwriting guidelines, pricing policies, eligibility rules, requirement specifications, existing rule exports, or spreadsheets with condition-outcome tables. Less structured narrative documents also work, but the Assistant may ask clarifying questions before drafting.
DecisionRules does not permanently store uploaded documents. Files are securely processed by the configured AI provider to enable document understanding during your AI Assistant session. They are never used to train public AI models.
Import & Export
Yes. You can download them via Business Intelligence API to periodically extract audit data and pipe it into your own data lakes, SIEM platforms, or business intelligence tools like PowerBI and Tableau.
No. The BI API queries historical log storage asynchronously. Your live production applications executing rules via the Rule Solver API remain completely isolated and run at maximum speed.
The BI API uses structured pagination to keep data transfers stable. Each API call can retrieve up to 1,000 execution records per page. To pull larger datasets, your BI tool or script iterates through the pages sequentially
Yes. Frequency Distribution, Time Series, and Raw Data Table all export to CSV. You get a ZIP containing the data itself plus a metadata file describing the export, so the numbers stay traceable once they leave the platform.
Yes, through the Business Intelligence API. The Integrations panel gives you the setup information for Power BI and generates REST API snippets in cURL, JavaScript, Python, PHP, .NET, and Java, already filled in with your selected BI API key, rules, and date range. Copy, paste, run.
Yes. The same BI API that powers the integration snippets can be called on a schedule to pipe audit data into your own data lake, SIEM, or reporting stack. Statistics is the fast way to explore, the API is the way to operationalize.
"Tell me more about..."
DecisionRules doesn't need to store PHI. The platform processes data in-flight and returns decisions. No patient data is persisted in the rules engine. For organizations that need full control, we offer private cloud and on-premise deployment options. SOC 2 certified. ISO 27001 compliant.
That's exactly the problem. Rules embedded in your core systems are expensive to change and impossible to audit independently. DecisionRules sits alongside your existing systems and calls rules via API. You externalize the logic without replacing the system. Think of it as a dedicated rules layer that makes your existing investments smarter.
Organization
Because the versions do not always overlap. When you run two versions in parallel you want the same window on both sides. When you have already switched, the old version lives in the weeks before the change and the new one in the weeks after, so each side needs its own window to have anything to draw.
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.
About Private Managed Cloud
Public Cloud is multi-tenant infrastructure shared across all DecisionRules customers, with automatic scaling and our standard SLA. Private Managed Cloud is a physically isolated environment with reserved capacity, your choice of AWS region, and dedicated dev, test and production environments. Same DecisionRules platform, dedicated infrastructure.
Private Managed Cloud scales with your sizing tier. Standard tiers handle tens to hundreds of thousands of business rules per environment. If your workload is larger, we offer fully custom sizing during the quote process.
There are no fixed limits on rules, projects, users, or API calls. Each Private Managed Cloud environment is sized to your specific workload, and limits are defined by the infrastructure you reserve. We size for your peak load, not your average.
Private Managed Cloud is built for teams that need reserved performance, strict data residency, or true isolation from other workloads. Typical customers include banks, insurance providers, and regulated institutions running sensitive risk rules. It's also a good fit for any team that has hit capacity or compliance limits on the Public Cloud.
Setup and Deployment
Yes. Most Private Managed Cloud customers run all three. Each environment is physically separated, and you can configure replication and redundancy independently per environment.
Yes. We offer three predefined sizing tiers based on typical workloads, or fully custom sizing if your requirements don't fit. We size for your peak load, not your average.
This process takes approximately 5 days from contract signing.
Private Managed Cloud is available across 17 AWS regions on 6 continents, including United States, European Union, United Kingdom, Australia, Brazil, and more. If you need a region we don't list, contact us. We can typically set up new regions on request.
Security and Compliance
You pick the AWS region your DecisionRules environment runs in, and your data stays there. Data is never replicated outside your chosen region. For redundancy, each region has two data centers within the same jurisdiction.
Private Link is a dedicated network tunnel between your application and your DecisionRules environment. Traffic never touches the public internet, even encrypted. Useful for banks and regulated institutions with strict network policies that prohibit data transit over public networks.
Yes. Each environment runs across multiple AWS Availability Zones by default, with automatic failover between zones. For production workloads, you can configure additional replication setups, including hot-hot deployment, to meet your availability targets.
Yes. All data is encrypted at rest using AWS-managed keys, and all traffic is encrypted in transit using TLS. DecisionRules is SOC 2 and ISO 27001 certified, with annual penetration tests and continuous vulnerability scanning.
Support and Migration
The DecisionRules team. We handle infrastructure provisioning, monitoring, patching, backups, and incident response. You focus on building rules. We make sure the platform runs.
SLA terms are customizable based on your response time, uptime, and support tier needs. We tailor SLA commitments to your use case during the quote process. Typical SLAs include 24/7 support coverage, defined response times for incidents, and uptime guarantees up to 99.99%.
Yes. Many customers start on Public Cloud and move to Private Managed Cloud when they need reserved performance, strict data residency, or true isolation. Migration is supported by our Professional Services team and typically completes within a few business days.
Working with Roles & Permissions
DecisionRules includes predefined Admin, Editor, and Reader roles for common collaboration scenarios. For advanced requirements, Custom Roles let you define permissions that match your organization.
Yes. Workspace administrators can update a user's role whenever responsibilities change, so permissions continue to reflect each team member's current work.
Custom Roles let you create permission models that match your organization's workflows, giving you more control than predefined roles alone.
Managing Team Access
Yes. Workspace administrators can add or remove members whenever needed, helping you keep access aligned with your team.
Yes. Users can participate in multiple workspaces, with permissions managed independently in each one.
Best practices
Give each team member only the access they need to perform their work. Built-in roles are ideal for most collaboration scenarios, while Custom Roles help support specialized responsibilities without compromising security.
Whenever possible, collaborate within a shared workspace instead of maintaining separate copies of business rules. Working from a single source of truth improves communication, reduces duplication, and helps every stakeholder stay aligned throughout the decision lifecycle.
Getting Started with CI/CD Pipelines
CI/CD Pipelines automate the movement of business rules between DecisionRules Spaces and environments. They use the Management API and DecisionRules Pipeline Tools to export, compare, back up, and import rule projects as part of an existing DevOps release process.
No. DecisionRules provides the Management API and pipeline utilities that perform the rule operations. Your existing CI/CD platform orchestrates when those operations run, where artifacts are stored, and whether an approval is required.
You need a source Space, a destination Space, their DecisionRules environment URLs, and a Management API key for each Space. The official Pipeline Tools run with Node.js and can be added to a standard CI/CD runner. A protected Git repository or object store is recommended for release artifacts and backups.
The tools are provider-neutral scripts. DecisionRules provides documented examples for Azure DevOps, AWS CodeBuild, and Google Cloud Build. The same approach can be used with GitHub Actions, Bitbucket Pipelines, Jenkins, OpenShift Pipelines, and other platforms capable of running Node.js commands.
Yes. The Pipeline Tools support DecisionRules Public Cloud, Regional Cloud, Private Managed Cloud, and on-premise deployments. Each source and destination is identified by its environment URL and Space-specific Management API key.
Promoting Rules and Spaces
The standard Pipeline Tools export and import an entire Space, including its rule resources and folder structure. For more selective workflows, the Management API also exposes operations for individual rules, versions, Rule Flows, and folders, allowing teams to build a pipeline around the scope they need.
Yes. Export the source and destination Spaces and run the comparison step before import. The Pipeline Tools can create a JSON comparison artifact that gives reviewers an overview of the rule changes between the two environments.
Yes. Approval is configured in your CI/CD platform. For example, the documented Azure DevOps workflow separates comparison and migration into different stages and requires approval before the migration stage can update the destination Space.
Publishing is a separate lifecycle decision. The pipeline moves the exported rule project; it should not be treated as automatic approval of unfinished business logic. Define the expected rule statuses in your release process and verify them before production traffic is directed to the imported rules.
Yes. The documented full-Space workflow backs up the destination, clears it, and then imports the selected source artifact. Because this is a replacement operation, the destination backup, environment comparison, and approval gate are important safeguards. A customized Management API workflow can use a narrower deployment scope when full replacement is not appropriate.
Yes. Your CI/CD platform controls the trigger. A pipeline can be started manually, scheduled, or connected to a repository event such as a commit or merge, depending on your release policy.
Validation and Recovery
Yes. The pipeline belongs to your DevOps workflow, so validation steps can be added before approval or after import. The official Pipeline Tools focus on exporting, comparing, clearing, and importing Spaces; teams can extend the pipeline with their own policy checks or post-deployment Solver API smoke tests.
Before deployment, the pipeline saves the current Production Space as a backup file. If the new release needs to be reversed, a recovery pipeline clears the affected Space and imports the selected backup. Production is then returned to the state captured before deployment.
No. Rule Versioning manages numbered iterations of an individual rule inside a Space. Pipeline recovery restores a saved snapshot of a Space or environment. Use Rule Versioning for the lifecycle of one rule and CI/CD backups for environment-level deployment recovery.
Store backups outside the destination Space in a protected Git repository, your CI/CD artifact store, or object storage such as Amazon S3 or Google Cloud Storage. Apply the retention and access policies required by your organization.
Security and Best Practices
Store every Management API key in the secret store of your CI/CD platform. Use a separate key for each Space, limit who can run production deployments, and never commit keys to the repository or print them in pipeline logs.
Yes. Separate Spaces create a clear boundary between work in progress and production-ready logic. Many teams use a Development, Testing or Staging, and Production progression, but the exact number of environments depends on their review and compliance requirements.
Export and back up the destination, compare it with the source, review unexpected changes, require the appropriate approval, and retain the deployed artifact. After import, run the validation or smoke tests defined by your release process.
Keep the recovery pipeline separate from the normal deployment pipeline, protect access to it, and test it before it is needed. Make sure the team knows which artifact represents the last known-good production state and how to select it during recovery.
Getting Started with Rule Versioning
Rule Versioning allows multiple numbered iterations of the same rule to exist side by side. All versions share the same Rule ID and Rule alias, while each version keeps its own structure, content, version number, and status.
Open the Rule Actions menu, the three-dot button in the rule editor, and select New Version. The same action is available by right-clicking a rule or opening its three-dot context menu in the folder or Business Rules view. DecisionRules copies the selected rule structure and assigns a version number one higher than the latest existing version.
Creating versions requires the corresponding Fork permission. The action can also be unavailable when the rule is locked, another version is currently being created, or versioning is not included in the current plan or configuration.
Every newly created version starts in Pending status. It cannot be executed through the Solver API, but it can be evaluated in Test Bench when Debug mode is enabled.
No. DecisionRules does not impose a limit on the number of versions that can be created for a rule.
Working with Rule Versions
A Published version is production-ready and can be executed through the Solver API. A Pending version is isolated from the Solver API, but it can still be evaluated directly inside DecisionRules using Test Bench.
Yes. Status is configured independently for each rule version. This allows one version to remain available in production while another is developed and tested in Pending status.
When a Solver API request does not include a version, DecisionRules automatically uses the latest Published version, the Published version with the highest version number. Specify a version explicitly when an integration must remain pinned to known behavior.
The remaining versions keep their original numbers. New numbering always continues from the highest existing version. For example, if v23 was deleted but v24 exists, the next new version will be v25.
Yes, supported rule types can be compared side by side. The comparison helps identify changed conditions, values, rows, branches, or script lines depending on the rule type. Only rules of the same type can be compared, and Rule Comparison is available for selected subscriptions.
An earlier version can be used as a clean rollback point. Select the known-good version and create a new version from it. DecisionRules copies its structure into the next sequential version, which can then be tested and published through the normal release process. This preserves the version trail instead of rewriting it.
Testing Pending Versions
Pending versions of Decision Tables, Scripting Rules, Decision Trees, and Rule Flows can be evaluated in Test Bench with Debug enabled. Lookup Tables must be Published before they can be evaluated. Integration Flows are executed through the Jobs API rather than the Solver API.
Importing and Exporting Versions
Yes. A selected rule version can be exported like any other rule. Rules use the DecisionRules JSON format, while Decision Tables also support spreadsheet-based export and import workflows.
Import behavior depends on the import method and source format. Always review the imported rule's status after import before connecting it to a production integration.
Yes. The Management API can be used to work with rule resources and their versions, making versioned rules suitable for automated backup, migration, and deployment workflows. The complete environment promotion process will be covered on the dedicated CI/CD Pipelines page.
Rule Versions and Rule History
Rule Versioning creates explicit numbered checkpoints for significant changes and releases. Rule History records saved states inside the current rule version each time the rule is saved. Use versions for controlled releases; use History to inspect or restore smaller editing changes within a version.
No. Saving creates a new entry in Rule History, not a new numbered Rule Version. A numbered version is created only when the user explicitly chooses New Version.
Yes. A historical save can be restored as the current state of that rule version, or cloned into a separate rule. Historical entries are read-only until one of those actions is selected. Rule History is not currently available for Rule Flow.
Getting Started with Auditing
Event Logs record changes to your rules: created, updated, deleted, shared. Service Logs record API calls to your space: the method, path, and response. They are connected, since one call can produce several changes, but they answer different questions. Event Logs tell you what happened to a rule; Service Logs tell you what request made it happen.
Audit Logs are a native, enterprise-grade tracking feature that records every single execution within your workspace. Whenever an application calls a Decision Table, Decision Tree, Scripting Rule, or Flow via our API, the engine captures the exact timestamp, the rule version used, the raw input data, and the final output returned. It serves as your permanent, tamper-proof system of record. More about Audit Logs you can find here: https://www.decisionrules.io/en/product/audit-logs/.
Event Logs and Service Logs run automatically for your space, so the trail is there whenever you need it. Decision-level Audit Logs are the exception: you switch those on per rule, so you only generate the ones you actually want.
Working with Auditing
Open any Event Log or Service Log entry and use Inspect to jump between them. Behind the scenes they share a correlation ID, a single identifier stamped on every record from one operation. Search either tab by that ID to pull up everything a call touched at once.
Yes. Send your own correlation ID as an x-correlation-id header on your API call, and the same value shows up in both Event Logs and Service Logs. The response hands it back to you as well, so your integration can capture it and line everything up on its side.
Event Logs and Service Logs are retained for 90 days, then removed automatically. An event and the call that produced it expire together. For decision-level Audit Logs, you set the lifespan yourself per rule, so you can match retention to whatever your industry requires.
Decision-level Audit Logs are built for exactly that. Capture the input and output of every solver run and pull it into your BI platform through the Business Intelligence API, or connect it straight to Power BI. It turns your decision history into something you can analyze, not just read.
IBM ODM Migration
No. Migration is a translation, not a rewrite. The business intent behind each rule carries over unchanged; only the underlying artefacts change shape, and most rule types map one to one (a decision table becomes a decision table, a decision tree becomes a decision tree).
Yes. In ODM, even fluent BAL rules only expose the vocabulary a developer has already prepared: fields like award or bonus amount exist in the dropdown because a developer built a Business Object Model and hand-verbalised each one. In DecisionRules business users can add a field themselves. Most day-to-day changes no longer need a developer at all.
Once you edit a rule and publish it, the change is live immediately. You don't need a separate deployment step or a developer to push it through, though you can still involve one if your process requires that extra review.
Yes. DecisionRules keeps Event Logs recording who made a change and when, so you can always trace back the history of a rule.
Barely. Your application still sends the same request and gets back the same shape of response, so the integration logic you've already built doesn't need to be rewritten. What changes is where that request goes: instead of hitting a Rule Execution Server running on your WebSphere instance, it hits a Solver API URL that DecisionRules generates the moment you publish the rule. In practice, this means updating an endpoint address (and the protocol it speaks) rather than rebuilding how your application talks to the rule engine.
Yes. If you have test cases from Decision Validation Services, we translate them alongside the rules and run them against the new DecisionRules versions, so you can confirm equivalence before cutting over. If you don't have a test suite, the AI Assistant writes one from the rule logic itself.
Getting Started with Organizations
An Organization is the highest administration level in DecisionRules. It allows companies to centrally manage users, authentication, shared settings, and multiple workspaces from one place.
Organizations are ideal for companies managing multiple teams or workspaces that want centralized administration while allowing individual teams to continue collaborating independently.
No. Teams continue working in their existing workspaces. Organizations simply centralize administration and company-wide configuration.
Working with Organizations
Teams group users working on the same projects or business areas, making administration and user management easier.
Departments organize multiple Teams into larger business units, helping companies mirror their existing organizational structure inside DecisionRules.
Department Managers oversee individual Departments and help distribute administrative responsibilities across larger organizations.
Organization Settings
Organizations support Single Sign-On through Microsoft, Google, and Okta.
Organizations allow you to centrally configure company branding, AI Provider settings, authentication, organizational structure, and other organization-wide preferences.
Organization administrators manage users, Teams, Departments, authentication, shared settings, and the overall organizational structure.
Connecting
Claude, ChatGPT, GitHub Copilot, VS Code, and Codex have their own connector entries. Cursor and other MCP-compatible clients connect through Smithery. DecisionRules is also published in the Docker MCP Catalog and Azure MCP Center.
Open the connector list in your client, find DecisionRules, sign in, and pick a Space. Clients that cannot complete a sign-in flow can authenticate with a Management API Key instead.
It defines everything the assistant can see and touch. It cannot reach rules in another Space and will not switch on its own. For a first trial, use a sandbox Space rather than one running production decisions.
Usually the wrong Space was selected. Connect again and check the Space picker, especially when your account has several Spaces.
Check that your client is in agent mode rather than plain chat mode. In Copilot and Cursor this is a separate toggle, while the tools can remain visible in either mode.
What It Can Do
Anything from a full rule to a single lookup. Common requests include creating a Decision Table from a description, turning an attached price list into a new version, generating test cases, running a rule against input, comparing versions, and finding dependencies.
Yes. You can solve a rule against any input and receive the result in the conversation. For a full pass and fail test suite, use Rule Tests in the editor.
Yes. MCP clients can hold several server connections at once, and your assistant can use them in one request. Each server is connected separately and DecisionRules does not need to know the others exist.
No. Generation runs through the DecisionRules AI Assistant, the same one built into the editor, trained on real rule logic and best practices and aware of your table structure.
Learn more: related documentation
Security and Governance
The assistant can change rules, but access is scoped to one Space, every change lands in version history, and nothing reaches callers until a version is published. Event Logs record every change and who initiated it.
Rule history captures every save, versions are explicit snapshots, and both support rollback in one click. The worst realistic outcome is a rollback.
No. Requests run under enterprise terms with no training on your data. DecisionRules holds SOC 2 and ISO 27001 certifications, with configurable data residency and SSO available. When you use your own model provider, its terms determine the no-training guarantee.
MCP vs the Management API
The API is for systems and repeatable calls. MCP is for conversations, authoring, and debugging. Most teams author and debug through MCP, then promote and keep changes in sync through the API.
No. Anything scheduled, reproducible, or high-volume belongs on the Management API. A pipeline that occasionally interprets instructions differently is not a pipeline.
Yes. Rules can be authored and debugged through MCP, then promoted and kept in sync through the API. MCP writes the draft, and the API ships it.
Customizing Your Brand
SVG is recommended for the best result. The logo is displayed within the available branding area, so using an appropriately sized horizontal logo helps maintain readability across the interface.
Branding can be managed from Organization → Settings → Organization Branding, where separate sections are available for configuring your logo and custom colors.
Yes. Logo and color settings are configured independently, so you can update your visual theme without replacing your existing logo.
Working with
Yes. White Labeling can be used with private DecisionRules deployments, including Docker. Branding configuration allows your deployed environment to carry your company's visual identity.
Yes. Your branding can be changed as your visual identity evolves without affecting your business rules or decision logic.
Editing Process
Yes. You can update cells, add columns, modify rule variables, and adjust input or output models in a single request. The Assistant processes all related changes together to maintain consistency.
No. The rule identity: name, alias, version and other rule settings are preserved.
Review, Safety and Availability
No. Nothing is saved automatically. The Assistant only creates a proposal. You must review and apply. You can discard or undo at any time.
The proposal may become outdated. If so, regenerate it to reflect the current rule version. Any prior changes you applied can still be undone.