5.3 Case Management, Queues, Assignment, Auto-Response, and Escalation

Case Management Model

A Case is a record of a customer question, issue, request, complaint, or support interaction. Cases can come from agents, Email-to-Case, Web-to-Case, Experience Cloud, integrations, phone work, chat, messaging, or manual entry. The admin configures fields such as Status, Priority, Origin, Type, Reason, Subject, Description, Contact, Account, Asset, Product, and Owner so the support team can triage and resolve work consistently.

Support processes control which Case Status values are available for a Case record type. This mirrors the sales process idea for Opportunities. A technical support team might use New, Working, Waiting on Customer, Escalated, and Closed. A returns team might use Received, Approved, Replacement Sent, and Closed. The admin should keep statuses reportable and operational. If every team invents similar statuses with slightly different names, dashboards and service metrics become unreliable.

Queues And Ownership

Queues let groups own records, including Cases and Leads. A queue can include users, roles, public groups, and other supported members. When a Case is owned by a queue, members can take ownership if they have access. Queues are useful for first-line triage, regional support, billing questions, partner support, and after-hours work. They also make list views and work distribution easier than assigning every new Case to a single manager.

Queue membership does not automatically mean a user can see every field or perform every action. Object permissions, sharing, field-level security, record types, and page layouts still matter. If a user is in the queue but cannot work the Case, check whether they have Read and Edit on Cases, access to the record type, visibility to related Account or Contact if needed, and access to the list view or console app.

Assignment Rules

Case assignment rules evaluate criteria and set the Case owner. A rule entry can assign to a user or queue. Entries are processed in order, so specific criteria should usually appear before broad catch-all entries. Assignment rules can be invoked from supported Case creation paths and user actions. In Setup and automation design, admins should know when the active assignment rule applies and when a Flow or integration is bypassing or replacing it.

Example assignment logic might route Priority High and Product A Cases to the Tier 2 Product A queue, billing Cases to Billing Support, and all remaining Web Cases to Tier 1. If a Case is not routed as expected, inspect the active rule, entry order, criteria logic, field values at creation time, and whether the creation path selected the assignment rule option. Also check for after-save automation that may overwrite the owner after assignment.

Auto-Response Rules

Auto-response rules send an email acknowledgement based on Case criteria. They are useful for confirming receipt, setting expectations, sharing a case number, or giving next steps. They do not choose the Case owner. A common exam clue is a requirement to send different acknowledgement emails based on language, product, priority, or origin. That points to auto-response rules, email templates, and organization-wide email addresses rather than assignment rules.

Be careful with customer communication. The email should not promise a response time that the organization cannot meet. It should not expose internal fields or confidential information. Test merge fields, sender address, deliverability, and criteria. If customers are not receiving the email, check the active auto-response rule, criteria, email template, support settings, deliverability, spam handling, and whether the Case creation source allows the rule to fire.

Escalation Rules

Escalation rules take action when a Case remains unresolved or in a certain state beyond defined time criteria. They can notify users, reassign the Case, or perform escalation actions according to business hours and criteria. Escalation is about time-sensitive service management, not initial routing. It should align with support commitments, priority definitions, business hours, and entitlement processes if those are used.

Case routing troubleshooting checklist

• Confirm the Case was created with the expected Origin, Product, Priority, Account, Contact, and record type.
• Check the active assignment rule and the order of rule entries.
• Verify whether the creation source used assignment rules.
• Review Flow, Process Builder legacy automation, Apex, or integrations that may update owner after assignment.
• Confirm queue membership and Case object permissions for users expected to work the record.
• For auto-response, check email template, organization-wide sender, deliverability, and criteria.
• For escalation, check business hours, age calculation, paused states, and criteria.

Business Hours And Priority

Support teams often have different commitments for urgent, standard, and low-priority work. Native Case features use fields such as Priority, Status, Business Hours, and entitlement-related milestones to measure time. Even before entitlements are enabled, admins should define priority values carefully. If every customer can mark every Case urgent, escalation becomes noise. Use page layouts, validation, customer portal settings, Flow, or assignment criteria to keep priority meaningful.

Business hours affect escalation timing. A Case created at 6 PM on Friday may have a different escalation target than one created at 10 AM on Tuesday. If the scenario mentions support hours, holidays, or regional service teams, check whether business hours are part of the configuration. Do not assume elapsed clock time is always the same as support time.

Scenario Walkthrough

A company wants web cases about outages to go to an urgent queue, send customers an immediate acknowledgement, and notify a manager if the Case is still New after one business hour. The right design uses a Case assignment rule for owner routing, an auto-response rule for the customer email, and an escalation rule for the delayed manager action. A single Flow could do pieces of this, but native features are clearer, easier to maintain, and match the standard support model.

Practice in a Developer Edition org by creating two queues, a Case assignment rule, and an auto-response rule with a simple email template. Create Cases with different Origin and Priority values and inspect owner, emails, and field history if enabled. Then add an escalation rule using test-friendly criteria. The hands-on lesson is that each rule type has a narrow job, and most troubleshooting starts with whether the right rule was active and eligible when the Case was created.