--- title: "Designing a case status model" url: "https://trailassembly.com/case-status-design/" topic: "Admin and Permissions" published: "2026-09-17T05:58:18+00:00" updated: "2026-10-06T13:57:04+00:00" --- # Designing a case status model **The two facts people get wrong:** Status is one picklist, and IsClosed is a property of each picklist value rather than a field anybody sets. You can have several closed statuses. You cannot have a status that is half closed, and every attempt to build one produces a “Pending” value that hides your real backlog. ## How the closed flag works Case Status is configured in its own setup page rather than the ordinary picklist editor, and each value carries a checkbox marking it as closed. Ticking it means a case with that status has IsClosed set to true, and the closed date is stamped. Several values can be marked closed, which is the platform’s answer to needing different closure outcomes. Closed, Closed as Duplicate and Closed with No Response are three statuses, all closed, all reportable separately. ## Keep the open statuses few A good model has four or five open values. New, In Progress, Awaiting Customer, Escalated is a complete model for most support teams, and one more for a genuine third-party wait is defensible. The test for whether a status earns its place: does a different person do a different thing depending on it? If two statuses lead to the same next action by the same team, they are one status. ## Why Pending hides problems Every org ends up with a status meaning “not our fault at the moment”. Pending, On Hold, Waiting. It is the most requested status and the most damaging one. The damage is specific. A case in Pending is open, so it counts in backlog, but nobody looks at it because the status implies somebody else owes something. Ageing continues. SLA clocks continue unless you have configured stopped time, which most orgs have not. The case sits there for eleven weeks and surfaces in a quarterly review. Three things make it safe, and all three are required: - **Name what is being waited on.** Awaiting Customer and Awaiting Vendor are different problems with different owners. Pending is neither. - **Stop the clock properly.** If you run entitlements, drive stopped time from the status rather than leaving it as a checkbox agents tick. If you do not, exclude the waiting time from your resolution metric deliberately, not accidentally. - **Automate the exit.** A [scheduled path](https://trailassembly.com/flow-scheduled-paths/) that chases the customer after a set period and closes the case after a second period. Without an automatic exit, waiting is permanent, because nobody reviews a list of cases that are officially not their problem. ## Status versus sub-status Once the open statuses are down to five, somebody will want detail back. That is legitimate, and it goes in a second field. A dependent picklist works well: Status drives the available Sub Status values, so In Progress offers Diagnosing, Fix Identified and Awaiting Deployment, while Awaiting Customer offers Information Requested and Reproduction Steps Requested. Reporting stays clean at the status level and the detail is there when a team lead wants it. ## Escalated is not a status Escalated describes an attribute of a case, not the state of the work. An escalated case is still in progress, or still awaiting the customer. The platform agrees: there is a separate Escalated checkbox that escalation rules set. Using a status value instead means you lose the underlying state, and a case that was Awaiting Customer before escalation now looks like nobody knows what it is waiting for. ## Changing an existing model Retiring a status is not a delete. Existing cases keep the value, and removing it from the picklist leaves records holding something nobody can select. Add the new values, update automation and list views, mass update the open cases, then deactivate the old values rather than deleting them. Deactivated values still resolve on historic records, so last year’s reports stay intact. ## Frequently asked **Can I make a status closed without it appearing closed to agents?** No, and wanting to is a sign the process needs a different shape. If work continues after closure, that work belongs on another record. **Do different [record types](https://trailassembly.com/record-types/) need different statuses?** They can, and it is usually a mistake. Shared statuses across record types keep cross-team reporting possible, and record-type-specific detail belongs in the sub-status. **What sets ClosedDate?** The platform, when the status changes to one flagged as closed. Reopening and closing again moves it, so a case closed twice reports only the second closure. --- Source: https://trailassembly.com/case-status-design/ Trail Assembly — independent Salesforce write-ups.