What is Decisions?

Decisions is a no-code business process automation platform, featuring a comprehensive Workflow, Integration, Reporting, and Rules engine, that enables businesses to own and quickly adapt their software. To do so, the Decisions Studio provides tools to build robust applications while the end-user Portal delivers the environment to run them.  

Among the many key features within the Studio is the suite of visual Designers for creating Flows, Rules, Forms, Dashboards, and Reports. In addition, the Data Structure Designer is used to create customized objects capable of interacting with a database for maintaining user and/or application data. This empowers business users (non-technical and technical) with the convenience of creating and maintaining business logic. 

Though business logic varies based on organizational needs, here are a few use case examples:

• Approval Tracking: Purchase Requests, Insurance Claim Handling, Travel Requests
• Evaluating Data Against Rules: Loan Applications, Risk Management, Financial Aid Inquiries, Inventory
• Document Processing: Clinical Trials, Employee On-Boarding, Compliance Audits
  

Integration options, another key feature found within the Studio, provide connectivity with existing infrastructure and user experience through RESTful API services. 

Client Requirements

As a web-based platform, Decisions runs in modern browsers capable of HTML5 and CSS3 without relying on plugins. The v7 Decisions Studio is designed to support Chrome and Edge browsers while the end-user Portal is less constrained.

To learn more, visit Browser Compatibility.

Technology

At a minimum, Decisions requires the following technical infrastructure to operate:

• Windows Server 2016 or higher
• .NET Core 3.1 (v7.0 - v7.1), .NET 5 (v7.2 - v7.9), or .NET 6 (v7.10+)
• MS SQL Server 2008 R2 or higher

To learn more, see Installation Requirements.

Decisions Automation Platform Architecture

Decisions Automation Platform architecture is based on three components:

• Front-end Client: Decisions Portal, API Client
• Back-end Application Server: Decisions Server (or IIS v10 App Pool)
• Database Source: Database Server (ex: MS SQL, MySQL, Azure) or Servers in MS SQL Server Cluster

The diagrams below illustrate how clients interact with the Decisions web application in Self Hosted and IIS (Internet Information Services) Hosted options.

To learn more, see Installer Hosting Options.

v7 App Self Hosted

The Decisions platform can be accessed using a front end web-based Portal and/or a series of RESTful API services. Decisions Server is a Windows Service, written in C Sharp (C#) language, that contains foundation service endpoints that communicate with the database backend; examples include the Flow Edit Service, which defines the Flow Designer functionality, and the Flow Execution Service, which is responsible for Flow Execution processes.

v7 App IIS Hosted

The Decisions platform can be accessed using a front-end web-based Portal and/or a series of RESTful API services. Unlike Self Hosted platforms, IIS Hosted environments use an IIS Application Pool and virtual directory structure (ex: baseportal.com/decisions) with foundation service endpoints to communicate with the database backend; examples include the Flow Edit Service, which defines the Flow Designer functionality, and the Flow Execution Service, which is responsible for Flow Execution processes.

A Database can be managed by multiple Servers in MS SQL Server Cluster. A single environment of the Decisions Platform can have only one Database because the platform has a single persistent source of data.

Because it is possible to have multiple Application Servers and only one logical Database, there are chances that communication with the database will be overloaded and dramatically slow down the process. In order to avoid this, the Decisions Platform stores as much data in the Application Server as it can, which is implemented by Caching.

In an environment with multiple Application Servers, all Application Servers talk to each other. If some data is changed in one Application Server, then it informs the other Application Servers to clear this data from the cache and get a new version of it from the Database. The data cannot change in the Application Server if it is changed directly in the database only; it should be changed through the Application Server, otherwise, the Application Server has to be restarted.

For successful communication between Decisions Server (or IIS App Pool) and Web Application that performs client interactions, the Decisions Platform uses a Pushback mechanism. For example, when somebody makes changes to the Flow in the User Interface, the Web Application sends those changes to the Service Host Manager using Flow Edit Service. Service Host Manager pushes some data back to the Web Application is able to make adjustments in the UI.