Business Rules Engine: define complex process logic without writing code

Most platforms say no-code. Then you try to build something that actually fits how your business works, and they hand you a script editor. WEBCON doesn't. The Business Rules Engine handles conditions, branching, routing, and escalations through visual drag-and-drop editor.

Readable and changeable by anyone. That's the point

When logic lives in a script, you need a developer to read it, understand it, and change it safely. Someone's on vacation, swamped, or off the project, and you open a ticket and wait. 

With visual rules, anyone with process knowledge can read exactly what a rule does. A business user spots the issue, gives precise feedback. The process champion makes the change. Then InstantChange™ does the rest. Every running instance updates immediately.

What is Business Rules Engine

The Business Rules Engine lives inside Designer Studio. You use it to define the orchestration logic behind your processes: who approves what, under which conditions, what escalation triggers, which path the workflow takes. 

You can build rules in two ways:  

• Drag and drop: pull elements from the dictionary panel into the work area and connect them visually.  
• Type directly: click into the editor and start typing. The platform autocompletes function names and suggests matching operators as you go.  

Rules return different data types depending on what you need. A value (text, decimal, or date) to set a default field. An execution condition (true or false) to control whether an action runs or which path a workflow takes. A list of users for task assignment. 

Rules can call other rules. You build modular logic once and reuse it across processes. The platform tracks where each rule is used, so you know the full impact before changing anything. Every rule appears in the auto-generated documentation, which means your process specs stay current without extra work. 

Form rules work the same way

The Business Rules Engine handles process logic. The Form Rule Engine handles form behavior: which fields appear, which are required, which values calculate automatically based on what a user selects. Both are visual.

Form rules generate JavaScript automatically. They handle browser and device compatibility. When you need logic that goes outside the form (Active Directory membership, data from an external system, a database query), you nest a business rule inside a form rule. That's the connection point between the two engines.

Real-world business rules examples

Here's what building a business rule looks like in Designer Studio:

There's no single right way to build a rule. The visual editor supports multiple valid approaches to the same problem, and every designer develops their own style. Since rules appear in auto-generated documentation, what you built also stays readable six months later when you come back to it. 

Order approvals by value and location

A purchasing process needs different approvers depending on order size and department. Orders above a threshold go to the Management Board. Below that, they go to the regional department head. The business rule checks both conditions and routes accordingly. One rule, no code.

Dynamic currency conversion

A global business rule pulls the current exchange rate for a selected currency on a selected date. A form rule uses it to auto-convert invoice amounts every time the user changes the currency or date. One rule, reused across multiple finance processes.

Role-based form visibility

A business rule checks whether the logged-in user belongs to a specific Active Directory group. It returns true or false. A form rule uses that result to show or hide fields. Anyone with process knowledge can read the logic. Anyone on the team can change it.