Cases stall when nobody can tell, from the record alone, who owes the next move. Fix that first: give every open status one owner of the next action and keep queues small and watched. Let escalation fire from rules or milestones, not from a forwarded email. Then report on how long cases sit in each status. In our experience, stalled backlogs are more often a design problem than a staffing problem.
Why do our cases sit in vague statuses?
Usually because the status list describes activity instead of responsibility. "In Progress" and "Pending" say something is happening without saying who must act, so nobody feels the clock.
A useful test: read any open status aloud and ask whose turn it is. "Waiting on Customer" passes, because the customer owes a reply. "Waiting on Engineering" passes, because a named team owes an answer. "Pending" fails, because it could mean either. Keep the open list short, usually five to seven values, and retire anything the team cannot define in one sentence.
Closed statuses deserve the same care. Salesforce lets you flag which status values count as closed, so you can separate "Resolved", "Closed – No Response" and "Closed – Duplicate". That split lets reporting exclude merged or abandoned cases from resolution metrics instead of flattering them.
| Status | Who owns the next action | Automation worth adding | Report it feeds |
|---|---|---|---|
| New | Queue members, until someone accepts | Auto-response; queue alert if unaccepted past a threshold | Unaccepted cases by queue and age |
| In Progress | The case owner | Milestone warning before the response or resolution target | Open cases by owner, oldest first |
| Waiting on Customer | The customer | Reminder email, then auto-close after a defined quiet period | Time spent waiting on customers by account |
| Waiting on Internal Team | A named tier 2, engineering or billing team | Notify that team's queue or channel; track the handoff date | Internal wait time by team |
| Escalated | The escalation owner or a manager | Set the escalated flag; alert the manager | Escalations by reason, product and account |
| Resolved | The customer, to confirm or reopen | Close automatically if no reply within the agreed window | Reopen rate by agent and case reason |
| Closed | Nobody | Survey send, if you run one | Resolution time and volume by reason |
Which case fields make reporting possible later?
Case Reason and Type, kept short and mutually exclusive, plus a product field. These are what root-cause reports, routing and AI classification all lean on.
Reason should describe the customer's problem, such as "Login failure" or "Billing error". Type should describe the kind of work, such as question, problem or request. When both lists grow past twenty values, agents pick the first plausible one and the data stops meaning anything. Capture the true root cause at closure in a separate field, because the reason a customer gives on day one is often wrong.
How do we stop cases bouncing between queues?
Give each queue a named owner, a clear scope, and a rule for what happens to cases that do not belong there. Bouncing happens when agents can move a case anywhere and nobody owns the misroutes.
- Write one sentence per queue describing the work it accepts, and share it with every agent.
- Require a reason when a case moves between queues, so you can see which routes misfire.
- Report weekly on cases transferred more than twice; each one usually points at one missing routing condition.
- Archive idle queues rather than letting cases die in them.
- Keep a monitored catch-all queue for genuinely unclassifiable cases, with a supervisor reviewing it daily.
How work is pushed from queues to agents belongs to Omni-Channel design, which we cover in a separate routing guide. The point here is ownership: a queue with no accountable lead becomes a parking lot.
Should we use escalation rules or entitlement milestones?
Use milestones when you have contractual response or resolution targets, and escalation rules for simpler age-based reassignment. Many orgs need both, but neither should overlap the other's job.
Escalation rules are the older tool. A rule contains ordered entries; each entry has criteria, a business hours setting, and the date field the clock counts from. Escalation actions fire when a case stays open past an "Age Over" threshold. They can reassign the case to a user or queue and notify people. Business hours can come from the rule entry, from the case itself, or be ignored. Only one escalation rule can be active at a time, so design its entries carefully.
Entitlement milestones are the more flexible approach. They track named commitments, such as first response, with warning and violation actions, and the clock can pause while you wait on the customer. If you already run entitlements, prefer milestone actions over new escalation rules so two clocks do not compete. Our Service Cloud setup guide covers entitlement basics; here the design question is which events should escalate.
How should tier 2, engineering and executive escalations work?
Keep the case owned by the frontline agent and bring specialists onto it, rather than handing the record away. Customers then keep one contact and the case history stays whole.
Case teams let you add engineers, account managers or product specialists to a case with defined roles and access. Predefined case teams help for recurring patterns, such as a security review team. For live collaboration, Salesforce offers swarming through Service Cloud for Slack, which starts a Slack conversation tied to the case record. Availability depends on your licensing and Slack setup, so check with your Salesforce account team first.
Executive escalations, where a customer emails your CEO, need their own path. Log them as cases with a dedicated reason, a named executive sponsor field and a short response target. Otherwise they live in inboxes and never show up in reporting. For a payments ISO, our Service Cloud build combined case routing, SLA escalations and Slack alerts.
Can Flow close cases that are waiting on the customer?
Yes, and it is a useful automation, but only with a reminder first and a clear message. Closing silently trains customers to open new cases instead of replying.
A record-triggered flow with scheduled paths can remind the customer after the status changes to Waiting on Customer. Later, it closes the case as "No Response". Stop the path if the customer replies or the status changes. Exclude escalated cases and strategic accounts, and test with real email replies, since inbound messages are what should reset the timer.
What about duplicates, outages and reopened cases?
Merge true duplicates, group outage cases under a parent, and decide in writing when a reply reopens a case versus starting a new one.
- Case Merge in Lightning Experience combines up to three duplicate cases into one master record, moving related lists and feed items across. It cannot be undone, and Salesforce documents restrictions for cases pending in Omni-Channel.
- For an outage, create one parent case and link affected customer cases with the Parent Case field. Update and close children together from the parent, often with a flow.
- Set a reopen window: a reply within it reopens the closed case, while a later reply creates a new case linked to the old one.
- Track reopens with a counter field. A high reopen rate on one reason usually means a knowledge gap, not an agent problem.
Salesforce also offers dedicated incident management objects in some Service Cloud editions. Check your contract before choosing between those and a parent-case pattern.
Why do customer replies create new cases?
Usually because email threading is misconfigured or still relies on the old Ref ID. Salesforce now recommends Lightning threading, which matches replies to cases more reliably.
Lightning threading puts a token in the subject or body of outgoing case emails and can also match on email headers. If neither finds a case, a new one is created. Salesforce has published a release update to disable Ref ID threading; check where your org stands before changing templates. Out-of-office replies and forwarded threads remain the usual source of duplicates, so pair threading with an auto-response rule that does not reply to auto-replies.
How do we measure time in status and backlog?
Turn on field history tracking for Status and Owner, then build reports on case history. For precise durations, stamp dates with Flow when a case enters and leaves each status.
Standard case age answers how old a case is, not where it waited. Field history shows each status change, which is enough for spot checks. For trend reporting, a small custom object or date fields recording time per status give clean numbers by team. Mind business hours: a case waiting over a weekend should not count against agents if your commitments are business-hours based.
A backlog dashboard needs only a few components: open cases by status and age band, cases waiting on internal teams by team, recent escalations by reason, and milestone violations. One cybersecurity client replaced a homegrown ticketing tool with Service Cloud. Its build included email-to-case, queues, severity tiers, escalations and auto-responses, and leaders gained real-time case dashboards.
How do case trends reach product and knowledge teams?
Through the root-cause field and a standing review. Data nobody reviews changes nothing.
On a fixed schedule, pull the top closure root causes and the most reopened reasons. Send product defects to the product team with case counts and affected accounts attached. Send repeated how-to questions to whoever owns knowledge, with a request for one article per pattern. Attaching articles to cases at closure shows which content is actually resolving issues.
Where does AI help with case management?
Case summaries and field classification are the practical starting points, provided your reasons and statuses are already clean.
Salesforce offers AI features that summarize case history for handoffs and suggest values for fields such as Reason or Type from past cases. Feature names and licensing shift between releases; confirm what your edition includes. Classification learns from your historical data, which is one more reason to fix vague picklists first. Sequencing AI across service work is covered in a separate guide.
What should a first cleanup phase include?
Statuses, queues and escalation triggers first, because every report and automation depends on them. Leave AI and new channels until those work.
- Map current statuses to next-action owners and merge or retire the rest.
- Trim Reason and Type picklists, and add a root-cause field captured at closure.
- Name an owner for every queue and archive the unused ones.
- Write the escalation triggers, then implement them in either milestones or escalation rules, not both.
- Switch to Lightning threading and test reply handling end to end.
- Add the waiting-on-customer reminder and auto-close flow.
- Turn on status and owner history tracking and publish a backlog dashboard.
For an existing Service Cloud org, our optimization team reviews case design, escalation logic and reporting together. Fixing one alone rarely holds.
