Status
Status in Salesforce is a field on a record that tracks where the record sits in its lifecycle.
Definition
Status in Salesforce is a field on a record that tracks where the record sits in its lifecycle. Status fields appear on most standard objects (Cases, Leads, Tasks, Solutions, Activities, Service Appointments) and on custom objects whenever an admin needs to track a record's progression through defined stages. The field is almost always a picklist with a controlled list of values, making the lifecycle predictable for reporting and automation downstream.
Status is one of the most-referenced fields in Salesforce automation. Validation rules check status values to block edits in the wrong stage. Workflow rules, processes, and flows fire on status changes. Approval processes route records based on status. Service Cloud Entitlements use Case Status to drive milestone timers. Picklist Value Sets let admins share a status value list across multiple fields on different objects, keeping the lifecycle definitions consistent across the org's data model.
How Status fields drive lifecycle, automation, and reporting across Salesforce
Where status fields appear in the standard data model
Salesforce ships with status fields on many standard objects. Case Status tracks support tickets through New, Working, Escalated, Closed with custom values per org. Lead Status tracks marketing-qualified leads through Open, Working, Nurturing, Converted, Unqualified. Task Status tracks activities through Not Started, In Progress, Completed, Waiting on Someone Else, Deferred. Service Appointment Status tracks field service work orders through Scheduled, Dispatched, In Progress, Cannot Complete, Completed. Each is a picklist with platform-defined defaults that admins customise to match the business process the team actually follows.
Picklist Value Sets and consistent status across objects
A Picklist Value Set is a reusable list of values that can be applied to picklist fields on multiple objects. The standard pattern is to create one Status Value Set with the values the org uses (New, In Progress, On Hold, Done) and apply it to status-like fields on Cases, Tasks, and custom objects. Edits to the value set propagate to every field that references it, so renaming a status value updates the option everywhere it appears. This is the canonical way to keep status lexicons consistent across the data model and avoid the drift that happens when admins maintain status lists per object.
Status-driven automation: workflow, flow, approvals, entitlements
Status changes are the most common trigger for Salesforce automation. A flow that watches Case.Status moving to Closed can trigger a CSAT survey email. A process that watches Opportunity.Stage moving to Closed Won can fire downstream order creation. An approval process can route Service Contract records when Status moves to Pending Approval. Service Cloud Entitlements use the Status field to start, pause, and stop milestone timers: a Case in New status starts a response milestone; a Case in Working stops it; a Case in Closed stops all milestones. The Status field is, in practice, the spine of declarative automation in most Salesforce orgs.
Status fields, validation rules, and stage gating
Validation rules are the most common way to enforce business rules tied to status. A validation rule can block a Case from moving to Closed if the Resolution Notes field is empty. It can require an Opportunity to have Products before moving to Stage Closed Won. It can prevent a Lead from being marked Converted without an associated Account. The rule uses the ISCHANGED() and PRIORVALUE() functions to detect a status transition and apply the gate. Validation rules fire on every update path (UI, API, Flow, Apex) so the gate is uniform regardless of who or what triggers the change.
Reporting on status changes: Field History vs Setup Audit Trail
Field History Tracking on the Status field captures every change with old value, new value, user, and timestamp. The history is queryable from the standard History related list on the record and reportable via the History object. This is the canonical audit trail for time-in-status questions like how long the case was in Working before Closed. Field History is limited to 18 months of retention by default; Field Audit Trail (paid add-on) extends retention up to 10 years for compliance-sensitive industries. For org-level changes like an admin renaming a status value, the Setup Audit Trail captures the change but does not link to the records affected.
Status as a closed-status flag and record locking
Some status values correspond to "the record is done." Case Status has a Closed checkbox per status value, which Salesforce uses to compute Closed metrics, time-to-close, and entitlement milestone behaviour. Lead Status has a Converted checkbox that gates conversion. Opportunity Stage has a Closed and Won pair of checkboxes that drive Pipeline reporting. These flags are platform-level attributes of status values, not custom fields the admin needs to add. Audit them when configuring a new status value because forgetting to set Closed=true on a closed status produces phantom-open records in dashboards and entitlement timers that never stop.
Custom object status patterns
Custom objects rarely have a status field out of the box; admins add one as a picklist. The standard pattern is to copy the structure of the closest standard object's status field: a controlled picklist with a small number of values, a default value set on creation, a validation rule that blocks invalid transitions (a record in Done cannot move back to In Progress without manager approval, for example), and Field History Tracking on the field for audit. This mirrors how standard objects work and produces a status experience that admins and users find familiar from day one.
Add and configure a Status field on a Salesforce object
A status field on a custom object follows the same pattern as the platform's standard status fields. The steps below cover the canonical setup: picklist with controlled values, default value, validation rule for transitions, history tracking, and a flow that fires on status change.
- Create the Status picklist field
On the object, add a picklist field named Status. Use a Restricted Picklist so users cannot enter ad-hoc values via the API. Apply a Picklist Value Set if the org has one for consistency across objects.
- Set the default value
Pick the initial status (typically New, Open, or Not Started). The default applies on record creation and removes the burden of users picking the right starting value.
- Add a validation rule for invalid transitions
Add a validation rule that uses ISCHANGED(Status) and PRIORVALUE(Status) to block invalid transitions: a record moving from Done to In Progress, a record skipping required stages, a record being Closed without required fields populated. The rule fires on every update path.
- Enable Field History Tracking on the Status field
In Object Manager, Field History Tracking, tick Status. The change history is captured on every status edit with user, timestamp, old value, new value. Reports on the History object surface time-in-status metrics.
- Add a record-triggered flow on status change
Build a record-triggered flow that fires when ISCHANGED(Status) and routes downstream work (notifications, child record creation, integration calls). Use Status as the criterion variable; the flow inherits the order of execution for status-driven side effects.
Prevents users from adding ad-hoc values via the API. Required for a controlled status lifecycle.
Shared status value list reusable across objects. Edits propagate to every field that references the set.
Per-field setting that captures status changes for audit and time-in-status reporting.
- Forgetting to set Closed=true on a Case Status value produces phantom-open records in dashboards. Always audit the Closed flag on every status value, especially after adding a custom Closed status like Closed Without Resolution.
- Picklist Value Set edits propagate immediately to every field that references the set. Renaming a value updates the option everywhere; check every dependent object before renaming.
- Field History Tracking captures only the changes made after tracking was enabled. Existing records have no historical status data until the next edit; do not expect retroactive history.
Trust & references
Cross-checked against the following references.
- Picklist FieldsSalesforce Help
- Picklist Value SetsSalesforce Help
- Field History TrackingSalesforce Help
- Entitlement MilestonesSalesforce Help
Straight from the source - Salesforce's reference material on Status.
- Picklist FieldsSalesforce Help
- Field Types OverviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Status in Salesforce?
Q2. What objects have status fields?
Q3. What do status fields drive?
Discussion
Loading discussion…