Client-Side Rules Engine in Quote Studio
The Client-Side Rules Engine in Quote Studio enhances performance by executing validation rules directly in the browser, improving responsiveness and reducing server load.
The Client-Side Rules Engine introduces a hybrid rule execution model for Quote Studio (CPQX). In this model:
Product Action Rules that perform actions such as Add Product, Remove Product, Update Product, or invoke a Custom Action Plugin continue to run on Apex.
Validation Rules that contain only Info, Warning, or Error messages run on the client (JavaScript).
Running validations directly in the browser improves responsiveness by displaying errors sooner and reducing unnecessary server round-trips. This enhancement improves overall performance and user experience.
This capability is controlled through an on-demand feature flag and can be enabled selectively.
Turning this feature on provides the following benefits.
Faster validation execution
Reduced Apex CPU and heap usage
Fewer governor limit violations
More consistent performance with large or complex quotes
Improved traceability using standardized logging
Enablement
This is an on-demand feature. Contact Zuora Support to have it enabled for your organization.
When the feature is turned off, the system behaves as before and executes all rules on Apex.
Execution flow
When rules are triggered in Quote Studio, they are grouped into two batches:
Product Action Rules
Validation Rules
The rules are executed in two batches:
Apex batch (Product Action Rules)
All Product Action Rules run on Apex in order of their priority.
Apex returns both the updated quote state and any server-side rule messages to the client.
JavaScript batch (Validation Rules)
The updated quote state is passed into the JavaScript engine.
Validation Rules are evaluated on the client in order of their priority.
Conditional Execution
If no Product Action Rules are present, the Apex batch is skipped.
If no Validation Rules are present, the JavaScript batch is skipped.
Example
Rule Setup
| Rule | Type | Priority |
|---|---|---|
| R1 | Product Action | 1 |
| R2 | Validation | 2 |
| R3 | Product Action | 3 |
| R4 | Validation | 4 |
| R5 | Product Action | 5 |
| R6 | Validation | 6 |
Evaluation order
The engine first runs all Product Action rules on Apex, then all Validation rules on Javascript, each group ordered by its own priority.
| Step | Executed Rule | Type | Why here? |
| 1 | R1 | Product Action | Lowest PA priority (1) → 1st among PA |
| 2 | R3 | Product Action | Next PA priority (3) |
| 3 | R5 | Product Action | Highest PA priority (5) → last among PA |
| 4 | R2 | Validation | Lowest validation priority (2) → 1st in JS |
| 5 | R4 | Validation | Next validation priority (4) |
| 6 | R6 | Validation | Highest validation priority (6) |
Therefore, even with priorities structured in an interleaved sequence (1-6), the result remains the same.
Server (Apex) batch: R1 → R3 → R5 (all Product Action rules, ordered 1,3,5).
Client (JS) batch: R2 → R4 → R6 (all Validation rules, ordered 2,4,6).
Logger
A unified logger module is included to provide consistent logging across validation rules. The logger supports four severity levels:
Error
Warn
Info
Debug
Each log message uses a standard prefix such as [ERROR], [WARN], [INFO], or [DEBUG].
Logging configuration
Logging is controlled per-browser-tab using localStorage:
| Key | Description |
|---|---|
| z_debug | Master switch. Set to "true" to enable non-error logs. |
| z_debugLevel | Minimum log level to display: error, warn, info, or debug. |
Error messages are always logged regardless of the localStorage settings.
Log Level behavior
The logger defines severity levels for messages, ordered from the highest severity to the most verbose:
error
warn
info
Debug
When the z_debugLevel key is set, the logging behavior is as follows:
| z_debugLevel | Messages Displayed |
|---|---|
| error | Error only |
| warn | Error + Warning |
| info | Info + Warning + Error |
| debug | All messages |