Ortoo Orchestrator vs DIY / In-house build

You built it to stay in control. Now you're managing the complexity.

Salesforce-native workflow orchestration, without owning the codebase.

Most Salesforce teams build their own workflow logic for a good reason: control. Over how work is handled, who handles it, how AI gets used, how fast things change.

Then comes the rest. Logic spread across Flows, Apex, routing rules, and AI agents. Manual fixes when routing breaks. Every change through admin queues and deploy windows. You're still owning it. You're just owning more of it than you wanted to.

Book a workflow-mapping session Compare side-by-side ↓

Built for: Salesforce platform owners · Enterprise architects · Service & RevOps · AI governance teams

The gap that matters

More automation doesn't give you more control. A layer does.

Salesforce gives you the building blocks. What it doesn't give you is a single place that defines how they behave together. Three things tend to happen as a result:

Fragmentation.

Execution logic spreads across assignment rules, routing, skills configuration, Flows, Apex, and AI agents. Nothing defines what happens end to end.

Setup dependency.

Most logic lives in Salesforce Setup. Changes require admins. Operations teams rarely change workflows themselves.

Slow change cycles.

Adjustments go through admin queues, testing cycles, and deploy windows. Changes that should take minutes take weeks.

Ortoo Orchestrator coordinates execution as one layer, and lets operations teams change workflows directly, under IT-governed boundaries.

In production

Running in place of what teams used to build and maintain themselves.

168,000+

Cases processed annually at Cars.com

120,000+

Records processed in 3 months at Assent Compliance

Full-time roles' worth of manual triage eliminated

Side by side

What each path actually involves, and how much of it you end up owning.

A capable Salesforce team can build most individual rows below, given enough time, headcount, and roadmap space. Ortoo Orchestrator delivers the same capabilities as a configured layer rather than a custom codebase, under IT governance, configurable by operations teams. Agents can also be built directly on Ortoo, AI-using or deterministic, without writing or maintaining the underlying infrastructure.

Capability	Ortoo Orchestrator	DIY / In-house build
Coordinates agentic and deterministic workflows in one layer	Native	Custom orchestration logic, usually in Apex
Skills-based, capacity-aware routing with real-time availability	Native (Q-assign engine)	Custom Flows plus scheduled Apex, rebuilt per team
Round-robin with workload balancing and rolling time-based limits	Native	Not natively supported, custom build
Human approvals inside agentic workflows	Native	Workaround chains across Flow plus Approval Processes
Bring your own LLM (GPT, Claude, Gemini, open-source, self-hosted)	Yes	Requires custom integration per provider
AI governance: where AI is used, which models, what it can influence	Configured per workflow, audited end to end	Custom guardrails, partial audit
Time for operations to change a routing rule	Configuration change, minutes	Flow modification, regression test, deploy cycle, sprints
Audit trail and execution visibility across the full workflow	Full, out of the box	Partial, spread across logs, debug records, Apex
Build new agents and tools by business users (under IT governance)	Configuration, not code	Requires admin or developer cycle
Cost when AI isn't needed for a step	Zero (deterministic mode)	AI infrastructure and monitoring still maintained
Maintenance burden as workflows accumulate	Bounded, handled by Ortoo	Compounds, each new workflow adds to the surface area
Continuity when the original builder leaves	Configuration is the documentation	Depends on documentation discipline
Operations team's ability to change workflows directly	Configuration, under IT-governed boundaries	Admin queue, testing, deployment window

Operations team's ability to change workflows directly

Ortoo Orchestrator

Configuration, under IT-governed boundaries

DIY / In-house build

Admin queue, testing, deployment window

When building it yourself makes sense: a single simple workflow, full control of every line, or logic that rarely changes. The cost shows up later, when complexity, volume, and change cycles add up.

The rows on capability are buildable. The rows on time, governance, and continuity are the ones that determine how much of it your team ends up owning.

The total cost

The cost isn't the build. It's the next five years of the build.

A custom Salesforce build has two costs: the cost of shipping version one, and the cost of running it from then on, engineering time, regression testing, AI infrastructure, on-call rotation, documentation upkeep, and the time every change spends in a deploy cycle. Ortoo Orchestrator covers both as one line item.

Pricing is per work item handled. AI costs scale with operational value, not consumption. Deterministic steps cost nothing. Ortoo handles the infrastructure, no codebase, deploy pipeline, or on-call rotation for your team to maintain.

Ortoo Orchestrator

One line item. Per work item handled. Deterministic steps cost nothing.

DIY / In-house build

Visible costs (build, AI usage) plus ongoing costs (maintenance, regression, on-call, dependency on key people).

What tends to happen

In-house builds get harder to manage as complexity adds up.

Salesforce builds usually work on day one. What gets harder over time is changing them, governing them, and knowing what they're doing. Three forces drive the drift, fragmentation, setup dependency, slow change cycles. The pattern shows up in five stages across most organisations:

Ship

A single workflow goes live. It works. The architecture is clean because there's only one of it.

Spread

Adjacent teams want the same thing. The pattern gets copy-pasted with variations. Three teams now run three slightly different versions of the same logic.

Patch

Edge cases surface. Workarounds appear in Flow, then in Apex. The original author writes a runbook.

Defend

Documentation lags behind reality. Changes carry regression risk. Some parts of the system get worked around manually because that's faster than changing them.

Replace

Leadership asks for a rebuild. By then the workflows are running production traffic, so the rebuild has to happen in parallel, and is usually also custom.

Ship

A single workflow goes live. It works. The architecture is clean because there's only one of it.

Spread

Adjacent teams want the same thing. The pattern gets copy-pasted with variations. Three teams now run three slightly different versions of the same logic.

Patch

Edge cases surface. Workarounds appear in Flow, then in Apex. The original author writes a runbook.

Defend

Documentation lags behind reality. Changes carry regression risk. Some parts of the system get worked around manually because that's faster than changing them.

Replace

Leadership asks for a rebuild. By then the workflows are running production traffic, so the rebuild has to happen in parallel, and is usually also custom.

With Ortoo Orchestrator, the same growth looks different:

Define once, not five times.

Operations teams define the workflow; specialised agents execute it. One layer, not five places to maintain logic.

Change in minutes.

Configuration changes don't go through deploy cycles. Operations move at their own speed, within IT-governed boundaries.

Start small, grow agent by agent.

One workflow first. Add from there. No re-architecture project, no big-bang transition.

Where control shows up

Four kinds of control that are hard to add later.

Real Salesforce environments are messy. Cases come in unstructured. Queues need monitoring. People move between teams. SLAs slip when no one's watching. AI agents get added on top of automation that wasn't designed to host them. A custom build can deliver any one of the controls below, the harder ones to add later are usually the ones that determine whether operations teams can move at their own speed.

Ortoo Orchestrator includes the four kinds of control built in from the start rather than added afterwards:

Workflow execution.

Work is handled according to a defined workflow rather than disconnected automation logic. Specialised agents perform specific tasks, enrichment, classification, routing, resolution, in sequence. Execution is consistent, traceable, and changeable without a deploy cycle.

AI behaviour and governance.

Teams set where AI is used, which models, what each agent is allowed to influence, and where deterministic logic takes over. AI usage is audited per step. No customer data is used for model training. No unbounded execution paths. The control AI governance teams ask for is built into the layer rather than wrapped around it.

Operational outcomes.

Workflows are designed around the outcome, case handled, lead routed, claim processed, rather than around individual automation steps. Fewer manual reassignments, fewer routing corrections, fewer "why did it do that?" investigations.

Speed of change, with full observability.

Operations teams configure routing, approvals, and workflow logic directly, within IT-governed boundaries. Changes happen in minutes rather than sprint cycles. And when a change doesn't land right, the fix is another configuration change, not another deploy: you're not waiting on a sprint to correct a sprint. Every step records what happened, why, where AI was used, and what was triggered, the audit trail is part of the system rather than something added on top.

Extend, don't replace

Start with one workflow. Keep what's working.

Most customers extend rather than replace. Flows that work keep working. Ortoo Orchestrator takes on the workflow where the in-house build is starting to strain, usually the one with the most edge cases, the most cross-team coordination, or the most AI involvement.

Service workflows are often the first beat, case routing, triage, response generation, because that's where AI gains tend to land first. Within a quarter, the orchestration layer is doing work that previously needed a custom architecture. Within a year, it spans service, revenue, and cross-system processes.

Cars.com

From email triage to full case lifecycle.

Started with email triage and account identification on inbound dealer cases, extending existing case workflows rather than replacing them. Expanded into SLA monitoring, revenue retention detection, and privacy workflows on the same orchestration layer.

33,600: Hours reclaimed annually
168,000+: Cases processed annually
~100%: Routing accuracy

Assent Compliance

From basic triage to deep orchestration across 16 teams.

Started with case triage on a single team handling multi-language, multi-tier support, alongside existing routing. Expanded into child object reading, agent-driven plug-in actions, and advanced file content extraction across 16 teams without re-architecting.

120,000+: Records processed in 3 months
16: Use cases orchestrated
15 of 16: Workflows classified as business-critical

Frequently asked questions

Build vs buy on Salesforce, common questions.

When does it make sense to stop building workflow automation in-house?

Usually one of three signals: a second or third rebuild of the same workflow in three years; the original author leaving and no one wanting to touch what they wrote; or AI agents being added to a stack that wasn't designed for them. When any of those apply, the running cost of the in-house build is typically already higher than the cost of an orchestration layer, even if it isn't yet on a budget line.

What's the total cost of building custom Salesforce workflows compared to using Ortoo Orchestrator?

The build itself is the visible cost. The ongoing costs, engineering time on maintenance and regression, AI infrastructure, on-call, documentation upkeep, the time each change spends in a deploy cycle, and dependency on the original builder, typically exceed the original build cost within 18 to 24 months. Ortoo Orchestrator covers all of those as work-item pricing tied to work items handled.

Can Ortoo Orchestrator work alongside Flows and automation we've already built?

Yes. Most customers extend rather than replace. Flows that work keep working. Native routing rules that handle simple cases keep handling them. Ortoo Orchestrator takes on the workflows where the in-house build is starting to strain, and the next workflow follows from there.

How is workflow orchestration different from a custom Apex / Flow architecture?

A custom architecture is fragmented by design: routing in one place, approvals in another, AI invocations in a third, integration logic spread across Apex classes. Each part works on its own; no layer defines end-to-end execution. Orchestration is a layer above all of those, defining what happens, in what sequence, under what conditions, and with what controls. Execution still happens in Salesforce; the orchestration is what coordinates it.

How does Ortoo Orchestrator handle AI governance and audit requirements?

AI is applied per step within a defined workflow, not as a standalone process. Each step records which model was used, what data it received, what it produced, and what action followed. Teams set boundaries up front, which models are allowed, which data they can see, what they can influence, where deterministic logic takes over, and those boundaries are enforced and audited per execution. No customer data is used for model training. AI governance, security, and risk teams can review AI usage the same way they review the rest of the workflow.

How do operations teams change workflows without losing IT control?

IT defines the building blocks, which functions exist, which models are allowed, what each agent can influence, where data can flow. Operations teams configure specific workflows from those building blocks: routing logic, approval steps, workload limits, agent behaviour. Configuration changes don't require a deploy cycle. Operations move at their own speed within boundaries IT has already set, the trade-off most platform owners are looking for, and one that's hard to retrofit onto a custom codebase.

How does Ortoo Orchestrator handle AI agents we've already built, or want to build later?

Ortoo Orchestrator coordinates agents from any source, agents built directly on Ortoo, Agentforce agents, agents from OpenAI, Anthropic, Google, open-source models, or self-hosted models. Teams can bring their own LLM provider and API key. Existing agents continue to function; new ones can be built natively on the orchestration layer.

What happens to the existing documentation, runbooks, and team knowledge if we move off the in-house build?

Most of the documentation becomes redundant rather than obsolete. Workflows are defined as configuration, which is readable directly. The audit trail is part of the system. Onboarding a new platform owner moves from working through runbooks to reading the configured workflows.

Does Ortoo Orchestrator work with Agentforce?

Yes. Many customers run Ortoo Orchestrator alongside Agentforce. Agentforce handles conversational AI interactions on the surface; Ortoo Orchestrator coordinates routing, approvals, deterministic workflows, and operational execution across systems underneath.

How does Ortoo Orchestrator's pricing model work?

Pricing is per work item handled, a lead routed, a case resolved, a request processed. Deterministic workflow steps don't incur AI execution costs. The result is a predictable line item rather than a consumption-based cost that scales with AI usage.

Take the next step

Map the workflows worth keeping, and the ones worth handing off.

A workflow-mapping session covers what your team has built, what's working, and where an orchestration layer would take on the maintenance.

Book a workflow-mapping session

Ortoo Orchestrator works alongside Salesforce Flow, Agentforce, external AI agents, APIs, ISV applications, and existing in-house automation. Available natively inside your Salesforce environment, no external infrastructure required.