Business Rules
Server-side pre-save rules that validate records and trigger workflows. Business Rules are the automation backbone — they let you enforce data quality and react to record changes automatically.
Anatomy of a Business Rule
Each rule has:
| Property | Description |
|---|---|
| Entity | Which entity this rule applies to |
| EQL filter | When the rule fires. Supports CHANGES(field) and DIDNOTCHANGE(field) operators comparing pre-save vs post-save values |
| Abort | If true, the save is rejected with a custom message |
| Message | The error message shown when the rule blocks a save (with locale support) |
| Applies on | create, update, or both |
| Workflow | When abort=false, this workflow is dispatched after the save |
| Sort order | Rules evaluate in ascending order; first matching abort rule wins |
Example: prevent closing a ticket without a resolution
- Entity:
ticket - Filter:
statusCHANGESto:closed^resolutionISEMPTY - Abort: true
- Message: "You must enter a resolution before closing the ticket."
Example: notify on high-value deal
- Entity:
deal - Filter:
amount>10000^ANDstageCHANGESto:won - Abort: false
- Workflow: "Notify sales manager" (an existing WP-PFWorkflow workflow)
Workflow integration
When a non-aborting Business Rule matches:
- The record is saved normally
pfm.<entity>.br_triggeredevent fires- The linked workflow executes with the record data as trigger payload
- If WP-PFWorkflow is installed, the workflow is auto-created when you create the BR
Cross-plugin automation
When you create a Business Rule, pfm_business_rule_created fires → WP-PFWorkflow auto-creates a linked workflow draft. When the workflow is created, pfw_workflow_for_br_created fires back → PFM persists the workflow_id on the BR row. This means: create a BR → a workflow appears automatically, ready to customise.