7.4 Validation Rules, Assignment Rules, and Escalation Rules

Validation rules enforce save-time policy

A validation rule evaluates a record during save and stops the save when the rule condition is true. It is one of the strongest admin controls because it applies across many entry points, including standard pages, quick actions, imports, APIs, and automation that attempts to update the record. That strength is also the risk. A poorly designed validation rule can block integrations, data loads, mobile users, and legitimate exceptions.

Validation rules live at Object Manager > Object > Validation Rules. A good rule has a clear business reason, a focused formula, and an error message that tells the user how to fix the record. The error should appear near the relevant field when possible. For example, when an opportunity moves to Closed Won, a rule may require Primary Contact and Signed Contract Date. The message should not say Invalid record. It should say what is missing.

Use validation when incorrect data must not be saved. Use guidance, dynamic forms, path guidance, screen flows, duplicate warnings, or reports when users need coaching but should not be blocked. This distinction appears often in real admin work. A hard block for missing purchase order number may be correct for booked orders. A hard block for missing competitor on an early opportunity may only frustrate reps and encourage fake data.

Bypass design should be deliberate. Some orgs use a custom permission such as Bypass Data Quality Rules for controlled admin or integration users. That bypass should be documented, assigned through permission sets, and monitored. Avoid profile-name exceptions that become brittle after a security redesign. Also avoid broad bypasses that let ordinary users ignore rules whenever work is inconvenient.

Assignment and escalation aid

Assignment rules are found in Setup for Leads and Cases. They evaluate criteria in order and assign the record when a matching entry is found. This is purpose-built routing, not a security grant. If a case is assigned to a queue, queue members may work it depending on object support and access. If a user cannot see related records needed for work, assignment alone may not solve the process. The sharing model, role hierarchy, teams, and permissions still matter.

The active assignment rule matters. An org can define multiple rules, but only one lead assignment rule and one case assignment rule are active at a time for the standard assignment rule mechanism. Admins should test how records enter the org: manual create, Web-to-Lead, Web-to-Case, Email-to-Case, API, Data Loader, Flow, and integrations may have different settings for whether assignment rules run. A common issue is an import that keeps the importing user as owner because assignment rules were not invoked.

Case escalation rules help service teams act when cases age or meet criteria. They can notify users, reassign cases, or take configured actions based on business hours and rule entries. Use them when service operations need time-based escalation tied to case handling. Use Flow or milestone features only when the requirement goes beyond what escalation rules can express or when the org's service model already uses entitlements and milestones.

Operational scenarios and tests

A common service scenario is premium case routing. New cases from strategic accounts should go to the Premium Support queue. Sev 1 cases should go to an on-call queue and notify a manager. Cases not touched for four business hours should escalate. This is not a reason to build everything in one flow. Case assignment rules can handle initial ownership routing. Escalation rules can handle age-based action. Flow can fill gaps such as creating an internal task or updating a custom field when routing alone is not enough.

Validation rules may interact with routing. Suppose a rule requires Product Family before a case can move to Working. Email-to-Case creates cases without Product Family because customers do not know the field. If the assignment rule sends cases to the right queue, agents can classify them before moving status. If a flow immediately changes status to Working, the validation rule may fail. The admin must test the whole process, not each feature in isolation.

Operational rule checklist:

• Confirm the exact record entry points and whether rules run for each one.
• Review criteria order and default outcomes for assignment and escalation rules.
• Test user, queue, and manager access after ownership changes.
• Test validation errors from UI, Data Loader, API, Flow, and integration users.
• Verify email alerts, custom notifications, and task actions do not duplicate each other.
• Document bypasses, inactive users, queue membership, and rule ownership.

Assignment and escalation should be monitored after release. Reports can show leads by owner, cases by queue, unassigned records, aged cases, and records stuck before a required status change. If routing looks wrong, inspect criteria order, active rule, user or queue availability, and entry point behavior before rewriting automation. Many routing failures are configuration or data quality issues, not missing custom logic.

Study traps include assuming validation rules only affect page layouts, assuming assignment rules grant visibility to all related data, and assuming escalation rules are a generic scheduler for any object. Keep each feature's purpose clear. Validation blocks bad saves. Assignment routes lead and case ownership. Escalation helps case operations respond to time and criteria. Flow fills broader automation needs when the built-in feature is not enough.