Traditional Decision Management Suites (DMS) and Business Rule Management Systems (BRMS) focus mostly on Decision and Business Rules modeling and execution. However, decisions and business rules don’t run in a vacuum. They need to consume data from internal systems, external datasources, processes, databases, documents and so on.
In some cases, data access and connectivity is almost always neglected and left to software development efforts or 3rd party orchestration.
Data Integration Requirements
The wide range of data connectivity requirements makes it very hard for software development teams to pre-build all required data adapters, create all required queries, and have results transformed and ready for decision models.
Chances are that much of the data the decision model needs is in some form of database with SQL language support. However, data may need to be connected from flat files such as Excel, CSV or PDF files. Alternatively, as is often the case in the modern age of computing, some parts of the data will be sitting behind a form of API – a REST API for instance, which can provide data about a specific customer coming from CRM platforms such as Salesforce, Dynamic356 and HubSpot.
Once the set of data is collected from various external datasources, and potentially in different formats (e.g. JSON, XML, Native objects), you need to mesh them together, validate and restructure them, and enrich them to create the context for the decision model.
Creating Decision-Ready Data
Here’s an example of a car insurance scenario designed to calculate the premium, which relies on the execution of different decisions, such as those shown in the diagram below:

Example of a decision graph with a trigger associated with a decision node called “Define Potential Theft Rating”
There are two inputs for the above model: the “High Theft probability” list coming from an internal database and “Car”, where the vehicle information is provided by the consumer of the service when the model is deployed as a service.
In the above model, the “Determine rating” requires the input of the “High Theft probability” list.
Direct Data Connection in Decision Graph
Any node in a decision graph has several types of events and triggers – After and Before the execution of a specific decision node where you can also do some extra work. These events and triggers are a useful time to load relevant data from different sources based on the needs of the specific decision node. This enables you to lazy load data rather than loading everything all at once.
When a node in a decision graph is selected, you can set the triggers in the properties windows as below:
For connecting to a database or a REST API, choose the option and fill in the necessary information, such as the URL Address and authentication.
Moreover, the pre/post execution events and triggers help reduce the flow steps that are not related to the actual business process, such as logging, sending of notifications, transitional calculations, etc…
Data Orchestration
Alternatively, you can create an orchestration around the need of your decision graph. This enables you to connect to any internal and external datasources of any types.

Drag and Drop from Toolbox to build the orchestration around the decision e.g. “Premium Calculator DRD”
Now, orchestration gives you flexibility to build up all the steps for connecting, querying, and transforming your data with a simple drag-and-drop.
There is a large, growing library of connectors to different databases (MS SQL Server, MySQL, Oracle, etc.), applications (Gmail, Twitter, LinkedIn, Salesforce, etc.), and any file formats (Image, PDF, Excel, JSON, etc…), and any REST API endpoint.
Database Queries
With either of the options – using Direct Data in the Decision Graph or Orchestration model – chances are you will be using a Database such as MSSQL, Oracle, etc… that supports SQL language for querying data.

An example of the visual query builder that allows composing SQL queries with drag-and-drop and selecting columns, relations, and conditions without programming skills.
The Visual Query Builder enables non-technical people to compose SQL queries visually, execute them and, perform complex filtering, define data rules criteria and parameters without knowledge of SQL or programming.
Conclusion
Traditional DMS and BRMS have long struggled with limitations connecting to various external datasources, and enabling non-technical users to take care of data requirements for business decisions.
As a result, non-technical teams, e.g. domain experts, operations professionals, etc… once they finish decisions and rules modeling, they have to rely heavily on software development and IT teams for rest of the project requirements relating to data connectivity, query building, data processing and context creation.
FlexRule X provides the ability to quickly and easily integrate data from databases, REST API services, online applications such as Gmail, Dynamic365, Salesforce as well as flat files such as XML, JSON, Excel, CSV, PDF and etc… to be simply integrated as part of the decision automation efforts.
Last updated September 22nd, 2023 at 03:16 pm, Published April 14th, 2015 at 03:16 pm
CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.
This approach is recognized by Gartner as the missing link to provide business value to organizations.
Hi Arash – I’m having trouble understanding what you mean here. You talk about exposing “the decision” as a service, but you have four decisions in your DRD. Does the service encapsulate all four (plus the BKMs)? If so, what orchestration do you need, other than providing the necessary data to the service? Perhaps your orchestration represents what happens inside the service, but it is odd anyway because the two BKMs are functionals, and would be called by the Determine Rating decision, yet you seem to have them orchestrated as separate tasks. Perhaps all will become clear in your next post 🙂
Hi Alan,
Thanks for the comment.
That is correct and good you point it out. Those KBMs are functional. There are two reasons for the orchestration in this article:
1. As datasources are external to DMN, we needed that orchestration to allow the data for “High theft probability auto list” be retrieved from database. (first task in the flow)
2. Show how the execution would happen, if you don’t use a DMN to deign the decision graph. In next one we replace the separate tasks of Decision Tables with the DRD.
Sorry for the confusion.