What it does

Every case carries a Status (state) and a Status Reason. Status reason transitions let you say which status reasons an agent may move to from each current status reason, so the picklist on the form is filtered instead of showing all thirty values the business has accumulated.

Key facts

• The Case (incident) table has exactly three status values: Active, Resolved, Canceled. You cannot add a fourth. All lifecycle modelling happens in status reasons underneath those three.
• Out of the box the Active status carries reasons such as In Progress, On Hold, Waiting for Details and Researching. Resolved and Canceled have their own sets, including the system-owned Merged reason.
• Status reasons are added in Power Apps: Tables > Case > Columns > Status Reason, choosing the parent status first, then adding the choice. You also set which one is the default value on the form here.
• Transitions themselves are configured in the legacy status reason transitions editor reached from the column definition — a separate screen from where you add the choices.
• Transitions are an opt-in behaviour per table and are only supported on Case among the service tables. Turning them on for Case has no effect anywhere else.
• Requires System Administrator or System Customizer to configure. Business users can't touch it.
• Transitions filter the UI. They do not stop code, plugins, flows or the Web API from setting any valid status reason value, so treat this as guidance, not enforcement.
• Status can only be set to Resolved through the Resolve Case command, never by editing the Status Reason field directly on the form. Transitions can't work around that.
• Adding a status reason to Case does not automatically add the matching value to the Case Resolution table's Resolution Type — that is a separate, manual, value-must-match-exactly step if you use the customisable resolution dialog.
• Each transition definition is stored per status reason, so a ten-value model means ten transition sets to maintain.

When to use / skip

Use it when the client has a real case lifecycle they can draw on a whiteboard — triage, with customer, with third party, pending change, awaiting confirmation — and agents are picking the wrong value. Filtering the list is the cheapest possible fix and needs no code.

Skip it when the model is four values and obvious, or when the client is still arguing about what the statuses mean. Locking down transitions on an unstable model just means you renegotiate the matrix every sprint. Also skip it if what they actually want is enforcement with an audit trail and mandatory fields at each step — that's a business process flow or a plugin, and transitions will only give false comfort.

Configuration decisions

• How many Active status reasons the lifecycle really needs. Every extra value is another transition set and another column on someone's dashboard.
• Whether "waiting on customer" is a status reason or a separate field. If SLA pause behaviour depends on it, that decision is made jointly with whoever owns the SLA design, because SLA pause is keyed on status reason values.
• Which status reason is the default on creation, and whether cases arriving from automation should land on a different one.
• Whether agents may move backwards (from On Hold back to In Progress) or only forwards. Most clients ask for forward-only and then immediately want an exception.
• Whether cancelled cases are part of the model at all, or whether the business treats everything as resolved with a reason.
• Who is allowed to reach the terminal reasons — transitions apply to everyone equally, so if managers need extra options, that's a security-role or form-level problem, not a transitions one.

Gotchas

• Reporting is built on these values. Renaming a status reason keeps the underlying integer value, but adding and removing values over time leaves historic cases sitting on reasons no longer in the transition matrix — agents then can't move those cases at all.
• Deactivating a choice doesn't retire it from existing records. You'll see it in views and in Power BI long after it's gone from the form.
• Transitions are silent when they block. The agent just sees a shorter list, with no explanation of why the value they expected is missing. Expect support tickets that read "the status is gone".
• Custom values you add for resolution have to be mirrored on the Case Resolution table with the identical numeric value, or they won't appear in the resolution dialog.
• Solution-layering status reason choices across dev, test and production goes wrong when someone adds a value directly in production; the values drift and the transition matrix stops matching.
• The transitions editor is the old UI. It survives, but don't build a training deck around its look — it has moved before and will again.

Consultant notes

• Get the lifecycle signed off on one page before you configure anything. A status model agreed in a workshop and configured the same week is fine; one that evolves through UAT is a rework machine.
• Demo it with a deliberately wrong click: show the agent trying to jump from Triage straight to a terminal reason and finding it absent. That lands better than showing the config screen.
• Tell the client plainly that this filters the dropdown and nothing more. If they need hard enforcement across integrations, price that separately.
• Check the SLA and routing designs before you finalise values — both consume status reasons, and changing them afterwards means retesting both.
• Before go-live, run a report of distinct status reasons on migrated cases and make sure every one of them still exists and has a way out.

---

Worth revisiting if Microsoft modernises the transitions editor, or if the client's SLA pause rules change.