FlexRule Server Nodes

◷ Reading Time: 7 minutes

FlexRule Server now supports a distributed and decentralized role-based architecture, enabling modular deployment and scalable execution across multiple node types.

Supported node roles include:

  • Asset Management: The governance vault of the platform.
  • Identity: The security and authentication layer.
  • Execution Controller: The coordinator of runtime execution.
  • Execution Worker: The runtime execution engine.
  • Workbench: The central host of the Server UI.

This architecture allows each node to operate independently while participating in a unified decision execution ecosystem.

Node Installation

Each node has its own separate installer. When installing the entire platform, all nodes must be installed, but they can later be upgraded independently.

This allows you:

  • Upgrade some nodes while leaving others unchanged
  • Avoid breaking changes during incremental upgrades
  • Maintain a stable environment during rolling updates
Nodes in FlexRule Open

Asset Management Node

Decision Asset Management (DAM) is the subsystem responsible for storing, organizing, versioning, and governing all decision-related assets in a unified, structured way. It provides a foundation for managing both raw files and structured objects that are used across decision modeling, simulation, execution, and training within a workspace.

  • A workspace defines the boundary of asset access and collaboration.
  • Roles control permissions to Read, Write, List and Delete.

Object Management

What is an Object?

An object is a structured instance of a known type (e.g., Customer, Quote, Scenario.Input). Each object:

  • Is typed according to a Fact Concept
  • Has a schema that enforces validation rules
  • Can be referenced in execution (Dynamic Decision Graph, Continuous Decision Model, AI Trainers)
  • Is stored with revision history
  • Lives in a workspace for governance and collaboration

Object Management in DAM (Decision Asset Management) allows users to define, store, version, and reuse structured, typed objects across projects and teams. Unlike raw files in Document Management, these objects are execution-ready, semantically validated, and tightly integrated with runtime components such as LiveContext and DecisionLang.

Unlike Document Management (which handles unstructured files), Object Management deals with typed, structured, and executable entities, giving your platform true object and collection management capabilities.

Identity Node

Formerly known as the Master Management node. The Identity Node is the central hub that manages who can access your FlexRule environment and what they are allowed to do. It keeps user and application accounts, roles, and permissions in one place.

Security and Permission

Accounts

Accounts enable a user or non-human user to interact with the platform either at the UI level (user) or backend (application)

  • There are two types of accounts:
    • User Account
    • Application Account

These are treated as “actors” in the system. Roles and privileges apply to both.

Roles

Roles define what set of actions can and cannot be done. A role defines a set of permissions to actions.

  • A role does not have impact until it is assigned.
  • The same role can be assigned to both user and application accounts as well as Groups (see below)
Role Assignments

Role assignment is what determines whether or not an actor can take an action.

  • Role assignment is the act of linking a role to an account.
  • This can be applied directly to user or application accounts.

Read more about Roles here.

Group

A group can contain accounts (user or application). Roles can be assigned to a group, and this reduces the need to repeat assignments across many accounts.

Read more about managing Groups here.

Privileges

A privilege ties together a resource (ex, a workspace), an actor (user, application, or a group), and a set of roles. This structure supports very specific permissions on a specific resource.

Privileges allow you to define what actions an actor can take on a specific resource based on the set of roles on the privilege which defines actions as either granted, denied or unspecified.

Read more about Privileges here.

Execution Controller

Formerly known as the Master Execution node. Execution Controller acts as the central orchestrator of the system. It coordinates task distribution and routing across agents. Also, it monitors health, load, and availability of agents. The Execution Controller knows which runtimes and services each agent supports.

Execution Worker

Formerly known as Execution Agent. Execution Worker is responsible for executing Services and Job requests. The Execution Worker defines which machines and endpoints to use. It also defines what runtime to load and what services it is responsible for.

Previously Know asIn FlexRule OPEN
Master Execution NodeExecution Controller Node
Execution Agents NodeExecution Worker Node
Master Management NodeIdentity Node

Deployment of FlexRule Server Nodes

With the modular, distributed architecture of FlexRule Server, there are literally endless configuration options, with the final solution driven by the product’s specific requirements and the customer’s architectural needs.

Any node can have multiple instances, allowing easy scalability or redundancy in the final environment. For example, one instance of the Identity node and one instance of the Workbench node can be coupled with multiple instances of the Execution Controller, which speak to a pool of many Workers.

These can be installed on one machine, but ideally you will distribute them across your network on different machines for scaling the execution process. Deploying multiple Nodes and putting them behind a load balancer that routes requests based on load. If an Identity Node is down, will let your load balancer route the request to another available Identity Node.

Execution configuration

In addition to deploying multiple nodes, FlexRule Server allows you to configure Execution Workers to be compatible with specific Jobs or Services. This allows certain Workers to be dedicated to executing those Jobs or Services, and other Workers reserved for other Execution tasks.

The high level of configurability allows customers to fine-tune their environment to seamlessly handle their specific requirements. Combined with the intuitive Workbench interface, it is easy to manage the implemented environment, quickly configuring Workers and administering Jobs and Services.

Updated on February 18, 2026

Was this article helpful?

Related Articles