Service workflows

Case lifecycle management in Salesforce

Case lifecycle management is the discipline of running every case from first contact to verified resolution as a single, observable workflow. It covers intake, triage, routing, the work itself, escalations, and closure, with the data, ownership, and timing of each step recorded against the case.

Standard Salesforce Service Cloud gives you the data model (case, queue, owner, status) and a handful of tools (assignment rules, Omni-Channel, Flow, macros). It does not give you one place where the lifecycle is defined and executed end to end. That gap is what most service organisations spend the next two years patching with Flows, triggers, and human escalation chains.

A handled lifecycle answers four questions at any moment for any case: where is it, who owns it, what should happen next, and what is blocking it. If your team has to open three tabs and a Slack channel to answer those, the lifecycle is not handled, it is reconstructed.

Service Cloud was not designed to fail. It was designed to give you the primitives and let you assemble the lifecycle yourself. Five years of assembly is what produces the patterns below.

Queue ping-pong

A case lands in a queue, gets picked up, gets reassigned because it was the wrong queue, and lands in another queue. Every hop adds minutes to handling time and zero value for the customer. The case data does not change, only the owner does.

Owner gaps between stages

Intake belongs to a digital team, triage belongs to a Tier 1 supervisor, complex work belongs to specialists, escalations belong to a manager. Each owner has a different view of what good looks like, and the case is the only thing that crosses all of them. Without a single workflow holding the stages together, the case waits at every handoff.

Manual handoffs disguised as automation

Assignment rules, escalation rules, and a dozen Flows look like automation. In practice they often only move the case to the next queue and then wait for a human to notice. That is not a handled lifecycle, that is a relay race with no baton.

Stage-level blind spots

Service ops can usually report on volume, backlog, and CSAT. Fewer can report on how long cases spend in triage versus routing versus work, or which stage owns the most aged cases. Without that view you cannot tell leadership where to invest, and you cannot tell the platform team where to fix.

1. Intake

Cases arrive from email, web, chat, voice, partner portals, and internal tools. Handled intake means every channel lands cases in the same shape, with the metadata needed for the next stage already attached. No human should ever copy a customer email into a case manually.

2. Triage

Read the case, classify it, enrich it, prioritise it. This is where AI steps earn their keep: language detection, intent classification, sentiment, customer tier lookup, duplicate detection. The output is a case that knows what it is and how urgent it is before any human looks at it.

3. Routing

The right case to the right person with the right capacity. Skills, language, account ownership, workload, shift, and SLA all play in. Standard Omni-Channel handles some of this; complex routing usually ends up in Apex or off-platform. A handled lifecycle treats routing as one step in the workflow, not a separate system.

4. Work

Agents and specialists actually resolve the case. Handled work means the case carries everything they need (history, related records, suggested next steps), and the workflow keeps tracking timing, status, and SLA the whole time. Stage transitions happen because the work happened, not because someone remembered to update a picklist.

5. Resolution

Verify the fix, communicate it, close the case, learn from it. Handled resolution closes the loop on SLA, captures the outcome in a reportable shape, and feeds the next round of triage and routing improvements. Aged cases never quietly become someone else's problem.

1. 01

   Intake

   Every channel, one shape

2. 02

   Triage

   AI where it helps, rules where it matters

3. 03

   Routing

   Skills, capacity, SLA weighed together

4. 04

   Work

   Agent resolves with full context

5. 05

   Resolution

   Closed, recorded, auditable

Ortoo Orchestrator does not replace Service Cloud, Omni-Channel, or your existing Flows. It sits above them and runs the workflow that calls them in the right order, with the right data, at the right time.

What stays in Salesforce

• Cases, accounts, contacts, knowledge: the data model is unchanged.
• Working Flows and assignment rules: kept and called as steps.
• Omni-Channel presence and capacity: still the source of truth for who is available.
• Reports and dashboards: continue to work, and now have stage-level data to read from.

What Ortoo owns

• The definition of the workflow itself: stages, transitions, conditions, owners.
• The orchestration runtime: which step runs next, with what inputs, against which case.
• AI steps where they help: classification, summarisation, drafting, decisioning.
• Stage-level observability: where each case is, how long it has been there, why.

The first workflow typically goes live in weeks, not quarters. There is no platform overhaul before the first result, and no rip-and-replace moment.

1. Pick one case type that hurts. High volume, clear SLA, frequent escalation, owned by one service group.
2. Instrument the current lifecycle. Where do these cases land, how long do they sit at each stage, who touches them, where do they stall?
3. Define the handled workflow. Five stages, named owners, named transitions, the AI steps that earn their keep.
4. Replace the current path with Ortoo Orchestrator running that workflow. Keep the Flows and rules that already work; call them as steps.
5. Measure for four weeks against the baseline. Handling time, backlog, SLA hit rate, stage timing.
6. Expand to the next case type. Use the same workflow definition with stage-level variations.

By month three you have two or three case types handled end to end, a baseline of what a healthy lifecycle looks like in your org, and a platform team that is shipping changes in days rather than running a backlog of Flow tickets.