The Rules engine automates document-processing decisions across the print, copy, and scan workflow. Each rule watches for a set of conditions at a specific point in the job lifecycle and, when they are met, applies one or more actions — forcing black & white or duplex, rejecting or redirecting a job, saving a preview, running a script, or sending an e-mail notification. Rules are administered from the React web console under Rules (route /rules, page title Rules Engine) and are available to administrators only.
Screenshot: Rules list view
In This Section
|
Page |
Description |
|---|---|
|
Step-by-step guide to creating, ordering, activating, and duplicating rules in the web console. |
|
|
Detailed reference for the four rule contexts — Login, Accept Job, Before Print, and Release Job — including when each fires and which conditions and actions are available. |
|
|
Complete catalogue of every condition field, comparison operator, and action type supported by the Rules engine, with usage examples. |
How Rules Work
Every rule belongs to a context that determines when it is evaluated. OptimiDoc provides exactly four contexts, each presented as a tab on the Rules Engine page with a badge showing how many rules it contains:
-
Login — evaluated when a user logs in to a device.
-
Accept Job — evaluated when a job is received from a device.
-
Before Print — evaluated before a job is sent to the printer.
-
Release Job — evaluated when a user releases a job for printing.
Each context exposes a different set of conditions and actions — for example, Add Watermark is only available in Before Print, and Print All Jobs only in Login. The full per-context availability is documented in the Rule Contexts Reference.
Priority and Cumulative Evaluation
Within a context, active rules are evaluated in priority order — the number shown in the list, where a lower number means higher priority. Evaluation is cumulative, not first-match: every rule whose conditions are satisfied contributes its actions, and matching does not stop at the first rule that fires. For example, one rule can force duplex while a lower-priority rule adds a watermark, and both apply to the same job.
-
Inactive rules are skipped entirely — deactivate a rule with the toggle rather than deleting it if you may need it again.
-
A Reject Operation action flags the job for rejection but does not halt evaluation of the remaining rules in the context.
-
Priority determines the order in which actions are applied; reordering rules (drag the list into a new order and choose Save Order) rewrites the priorities to a clean sequence.
All conditions within a single rule are combined with AND logic — the rule matches only when every one of its conditions is satisfied.
Building a Rule
Rules are created and edited in a dialog with three tabs — General (name, context, priority, active state), Conditions, and Actions. A rule requires a name, at least one condition, and at least one action. Saving validates the rule's structure only; there is no dry-run, test, or simulation mode, so verify behaviour on a low-priority or clearly scoped rule before rolling it out widely. Existing rules can be duplicated to use as a starting point.
In Summary
The Rules engine turns OptimiDoc from a passive print and scan gateway into an active policy enforcement point. By attaching condition-driven actions to the four lifecycle contexts, administrators can enforce duplex and mono printing to cut costs, block or redirect jobs, watermark sensitive output, capture previews for audit, and notify users — all without touching the client or the device. Because evaluation is cumulative and priority-ordered, several complementary rules can shape a single job, so plan priorities deliberately and keep unused rules deactivated rather than deleted.