Rules in Approval Workflows
Business rules are enforced in the approval pipeline as well as on direct saves. The gate is at the far end: when the change is written, not when it is proposed.
When a submitter saves
Nothing is checked yet. A submitted change is a proposal, not a row — it lives in the approval request until someone applies it, so there is no data to validate. The submitter can send anything.
When an approver applies a submission
Rules run at apply time, against the values in the pending change. Filling rules run first, then the checks, exactly as on a grid save.
- Error rules block the apply. The whole approval is rolled back and the approver sees which rule failed, on which column, with its message.
- Warning rules let the apply through. The rows are committed with their warning markers.
The message names the rule, the column and the reason, so the approver can send the request back with something the submitter can act on.
Force approve does not bypass error rules
An administrator using Force approve gets the same error-rule check. If applying the submission would write a row that breaks an error rule, the force approval is refused with the same explanation. Warning rules do not block a force approval.
This is deliberate. An error rule marks data that is definitively wrong and should not reach the master record under any circumstances. If an emergency needs it bypassed:
- Open the entity's Business Rules tab.
- Click Disable on the rule.
- Apply the submission.
- Click Enable to switch the rule back on.
- Run Validate Now so the row that got through is flagged.
Deletes
Rules do not apply to a delete. There is no row left to check.
Related
- Approval Workflows — the full propose, review, apply cycle
- Role: Approver — the review screen this message appears on
- Role: Administrator — force approve and what it is for
- Business Rules Overview — severity and where rules run
- Validating Entities — flag a row that got through