Workflow orchestration

Operational workflow management in Salesforce

Operational workflow management is the layer that sits above automation. When one step finishes, the right next step starts, with the right owner, the right context, and a record of what happened. Most Salesforce environments have automation for individual steps: Flows that fire on case creation, queues that hold work, routing rules that assign by criteria. What they rarely have is a single defined path from intake to resolution that owns the transitions between those steps.

Salesforce gives you the building blocks. Cases are created automatically, queued by type, assigned by rule, escalated on a timer. Each piece does its job in isolation. The handoff from triage to routing, from routing to the agent, from the agent to resolution: none of those transitions are owned by the platform. They depend on informal practice, manual intervention, or the judgment of whoever is watching the queue.

Service workflows break between steps, not within them. The patterns below are already visible in your team's weekly review.

Cases reach the wrong agent, or reach the right agent at the wrong time. A senior agent or operations lead reviews the queue, reassigns, and continues. The rate is not measured as a cost; it is absorbed as normal operating practice. Each reassignment is a handoff the workflow did not own, and the cost compounds with volume.

Escalation rules fire on timers. They cannot fire on context that arrives after case creation: a second contact from the same customer, a status change in a linked account, a missed response that has pushed the case past recoverable. Those signals require a person to notice them. When no one does, the SLA breach appears in the report, not before it.

Flows run on creation. Routing rules fire on assignment. Queues hold work between stages. Each automation does its job; none of them owns the gap between automations. Work accumulates in those gaps. Senior agents close them manually. The system functions. The outcomes depend on the people holding it together, not on the system itself.

When a backlog builds, there is no view inside the execution layer of where work is held, who owns it, and which cases are approaching SLA risk. That information lives in dashboards assembled from reports. Monitoring and execution are separate systems. Diagnosing a stalled case means investigating across both, after the problem has already occurred.

A case is handled when every stage has a defined owner and a defined output. Ortoo Orchestrator frames this as five stages, each owned by the workflow rather than the person monitoring the queue. The same model applies to revenue workflows, claims handling, and request management.

Work enters through a defined channel. The record is created with context attached: case type, source, initial classification, and account relationship. Missing fields are requested before the case reaches triage. The intake stage does not depend on the quality of the inbound data; it defines and enforces the minimum required.

The case is assessed before a human picks it up. Priority, type, complexity, and SLA state are evaluated at intake. AI is applied selectively where content interpretation is needed; deterministic logic handles classification and routing criteria. Every case arrives at the queue already prioritised.

The case reaches the right agent the first time, based on availability, skills, workload, and SLA state. Not based on a queue a senior agent monitors and manually adjusts. Round-robin, skills-based, and capacity-aware routing are configured options, not custom Apex. The routing decision is auditable and adjustable without a development request.

The agent has what is needed to resolve the case: full context, prior interactions, and a defined next step. Escalation is part of the workflow, not discovered after the SLA fires. If a case stalls or breaches a threshold, the workflow handles the exception without manual intervention.

The outcome is recorded with a complete audit trail: who owned the case at each stage, what actions were taken, how long each stage took. The workflow knows the case is done. Downstream steps are handled automatically.

1. 01

   Intake

   Record created, context attached

2. 02

   Triage

   Classified before anyone picks it up

3. 03

   Routing

   Right agent, first time

4. 04

   Execution

   Resolved with full context

5. 05

   Resolution

   Closed, audited, complete

If you built the existing Flows, queues, and routing rules, none of that changes. Ortoo Orchestrator coordinates above those layers, not inside them. The boundary is precise.

What stays in Salesforce

• Flows and process automations already running.
• Queue structure and existing routing rules.
• Agentforce agents and actions in use today.
• Standard objects, data model, and security permissions.
• Existing reports, dashboards, and entitlements.

What Ortoo Orchestrator owns

• Coordination logic above individual automations.
• Stage transitions and handoff rules.
• Routing decisions based on capacity, skills, and SLA state.
• AI steps applied at defined stages, within defined boundaries.
• Audit trail across the full lifecycle.
• Visibility into where work is at any stage, in real time.

The net result for the platform owner: existing automations become more predictable without being rebuilt. Operations teams adjust workflow rules without filing a development request. The platform team retains architectural ownership. The coordination layer works within the structure already in place.

1. Pick the one case type that generates the most manual coordination right now. That is the first handled workflow.
2. Map the five stages for that case type: what intake requires, how triage should work, what routing criteria matter, what the agent needs, how resolution is recorded.
3. Identify the one or two handoffs where work most often stalls or misroutes. Those are the coordination gaps Ortoo closes first.
4. Configure the workflow in Ortoo Orchestrator, above the Flows and queues already running. Nothing existing changes.
5. Go live. Measure reassignment rate and time-to-resolution against the baseline from the week before.
6. Expand to the next case type from the same foundation. Each new case type is a separate Function Instance, configured the same way.

By month three, most teams have two or three workflows coordinated end to end. The Flows have not changed. The routing rules have not changed. The handoffs between them are now owned by the system.