Service and Support Applications
Case handling
The service domain rewards knowing which rule does what, and in what order. Cases are created manually, by Web-to-Case, by Email-to-Case, or from a channel. Support processes and record types give different status picklist values per case type. Queues hold unowned work, assignment rules push cases to a user or queue, auto-response rules send the acknowledgment email, and escalation rules re-evaluate case age and can reassign or notify when an SLA is breached.
Traps
- For case and lead assignment, only one rule can be active per object. With auto-response rules, several can be active and are evaluated in order, first match wins.
- Assignment rules fire on creation and on edit when Assign using active assignment rule is selected; they are not a background job.
- Escalation rules depend on case age and require an owner that is a user or queue; they will not fire on cases that never meet entry criteria.
- Entitlements and milestones require Entitlement Management to be enabled and an entitlement process attached to the case.
- Web-to-Case and Email-to-Case must be enabled and the generated URL or address actually used.
Console and Omni-Channel
Service Console surfaces related records, macros, and quick text. Omni-Channel routes work by capacity and presence status; an agent who goes offline mid-case stops receiving new work.
Worked example
Web-form cases all land on the default owner even though an assignment rule exists. Check whether the rule is active, whether the rule entry order places the specific criteria first (the first matching entry wins and processing stops), and whether the target queue has members. Rule entry order is the usual culprit, not the rule logic.
Rule of thumb: routing problems are order-of-entries problems far more often than they are logic problems.