Rule Overview

Rules are used by applications to evaluate data, enforce policy, and trigger actions. The rule engine in ‘Decisions’ allows the same business user who knows and owns business logic to be able to automate, maintain, test, and deploy rules created in a natural visual design environment.
The Decisions Platform provides multiple rule styles, all sharing the same graphical design environment.

‘Decisions’ includes a set of visual rule designers allowing rules to be configured in different formats. The different formats are to allow rules to be designed in the same way they would be drawn on a whiteboard or typed in an email.
The structure of rules is easily built and read and understood by the business and the technical people within an organization.

Uses of Rules

Rules can be used in a number of different ways. These include:

  • Consumed by API from another application. This allows a customized application to externalize its rules in a way that they can be maintained outside of custom code.
  • Used in a batch process over data.
  • Fully automate interactions in a workflow. By having a set of rules to automatically make workflow decisions, often common user tasks can be avoided.
  • Make forms more interactive. Visibility, validation, live data updating is all provided by the rule engine.
  • Provide meaning for data on dashboards. This includes filtering out (for security or lack of relevance), coloring, summarizing, etc.
  • Security functions in the user and design portal.
  • Hiding user actions that are not relevant.
  • Etc.

Rule Inputs/Results

Rules take in data elements and produce a result. The data elements fed to a rule can be either simple values (like text or numbers) or complex data (like a policy, a medical record or person).

Rules evaluation can be one of the following types.

True/False or Return Data

Rules are commonly thought to make decisions – True/False. However… rules can be built to return data values – either simple decisions (logical result) or any other data type or data value. For instance, a rule could return a percentage of a loan or validation issues after evaluating a data structure.

Trigger Actions

Rules can also be used to trigger actions. Actions (using the flow designer) can be triggered by either a true or false evaluation of a rule. For instance, when a rule evaluates a true, you could send an email or even write a value to a database. When combined with – user interactions and assignments can be automated.

Using Rules From Other Applications

Rules need to be called by an application or a workflow in order to run. These applications will generally use the result of the rule as a guide to performing additional functionality. There are a number of different mechanisms where rules can be accessed by application functionality.

Service Interface

Any rule can be called using a SOAP or REST (XML or JSON) service interface. This can be done through a generic rule execution service or a specific service endpoint can be generated for each rule or rule set. Each rule has an integration page that shows all of the different service interface options and provides sample data structures and/or code for the integration.


Message Bus

Rules can also be triggered by configuring rules to be run as a result of a message across an infrastructure like RabbitMQ, MSMQ or IBM MQ Series. High performance or high throughput environments often benefit from a messaging infrastructure for guaranteed message deliveries with retries, load distribution, and work prioritization.

Running Rules On Schedule

Rules can be run on a schedule – where data is looked up in a database, FTP server, email inbox, or another mechanism. This data can then be processed through a rule or a ruleset triggering actions or having results passed out to other systems or databases.


Running rules on batches of data

Large batches of data can be fed into a rule engine by flows. These flows can also handle the result of the rules execution. ‘Decisions’ has the management of both flat files (csv, excel) or structured files (json/XML) as well as stored data prebuilt.