Carlos EscasainCommercial Systems & Process Architect
ENES
Capability map

Capability 06 · Technology

Automation

Automate the path. Keep the judgement visible.

I design automation as stateful process execution—clear triggers, bounded actions, human decision points, explicit exceptions and safe recovery.

See the approach Browse the reference cases

Trigger → rule → action → decision → next stateOne transition, from approved opportunity to active customer. Choose a layer to see what runs itself, who decides, and what happens when a step breaks.

Read the transition by
From approved opportunity to active customer: what happens at each step, its automation mode, the run state and the recovery if it breaks
Stage01Approval gate: Trigger02Decision: Rule03System action: Action04Human action: Decision05Lifecycle state: Next state06System action: Downstream
What happensOpportunity reaches ApprovedEligible for customer creation?Customer creation request → ERP processingFinancial validationCustomer activatedOnboarding tasks, price list, data platform
ModeHuman — ownsAutomated — ownsOrchestrated — ownsHuman — ownsAutomated — ownsOrchestrated — owns
Run stateCreatedRunningWaiting externalWaiting on a personRunningCompleted
If it breaksNoneNot eligible → stop, say whyTimeout → resolve by key, resumeRejected → back to sales, with reasonGuard: activate oncePartial → retry the missing step only
  1. 01TriggerOpportunity reaches Approved · Human
    What happens
    Opportunity reaches Approved
    Mode
    Human — owns
    Run state
    Created
    If it breaks
    —
  2. 02RuleEligible for customer creation? · Automated
    What happens
    Eligible for customer creation?
    Mode
    Automated — owns
    Run state
    Running
    If it breaks
    Not eligible → stop, say why
  3. 03ActionCustomer creation request → ERP processing · Orchestrated
    What happens
    Customer creation request → ERP processing
    Mode
    Orchestrated — owns
    Run state
    Waiting external
    If it breaks
    Timeout → resolve by key, resume
  4. 04DecisionFinancial validation · Human
    What happens
    Financial validation
    Mode
    Human — owns
    Run state
    Waiting on a person
    If it breaks
    Rejected → back to sales, with reason
  5. 05Next stateCustomer activated · Automated
    What happens
    Customer activated
    Mode
    Automated — owns
    Run state
    Running
    If it breaks
    Guard: activate once
  6. 06DownstreamOnboarding tasks, price list, data platform · Orchestrated
    What happens
    Onboarding tasks, price list, data platform
    Mode
    Orchestrated — owns
    Run state
    Completed
    If it breaks
    Partial → retry the missing step only
Automated where the rule is clear, human where judgement matters, orchestrated across systems—and every step knows how it recovers.
01What automation meansNot a faster click

Not “replace a click with a flow”. Reliable process execution.

Automation moves work when the rule is clear, stops for judgement when it matters, shows where it stands and recovers when something breaks.

It is not
  • Adding flows until manual work disappears
  • Chaining triggers with side effects
  • Turning every decision into a rule
  • Assuming success because a job ran
  • Hiding exceptions in admin logs
  • Retrying blindly
  • Making users wait for long-running technical operations
That removes clicks. It does not make the process run reliably.
It is
  1. Trigger conditionsWhich business state starts it—and which does not.
  2. OwnershipA business and a technical owner for every automation.
  3. Rule vs judgementAutomate the deterministic; keep judgement with people.
  4. StateModel the run and the record, not just the trigger.
  5. IdempotencyDesign every step to run twice safely.
  6. Failure planningClassify failures; not every one is a retry.
  7. ProgressShow users what is pending, running or waiting.
  8. EscalationWaiting has a clock and a next owner.
  9. ReconciliationDetect downstream state that no longer matches.
  10. OutcomesMeasure the business result, not the job status.
Four principles, applied below
  1. 01Automation should remove waiting, not remove accountability.

    Every automated step still has an owner who answers for its outcome.

    Automation boundary
  2. 02If a process can run twice, design it to run twice.

    Safe reruns are architecture, not a bug fix.

    Run state machine
  3. 03Successful execution ≠ successful business outcome.

    A job that finished can still have left a customer half-created.

    Observability
  4. 04A human approval is not an automation failure.

    It is an intentional boundary—a designed wait with a clock and an owner.

    Automation boundary
02My approachTen steps · the flow comes later

From process state to governed execution.

Ten moves from the business state that starts an automation to the people who own it after go-live. Building the flow comes after the first seven.

01Start from the process state

Step 01 · The question

What business state triggers the automation?

Triggers are business states, not field edits.

For example
  • Lead becomes qualified
  • Opportunity becomes approved
  • Account enters At Risk
  • RFQ arrives
  • Monthly review period starts
ProducesTrigger / state definition

Second-orderA trigger on “any change” runs on changes nobody meant as a business event

  1. Start from the process state
    Step 01 · The question

    What business state triggers the automation?

    Triggers are business states, not field edits.

    For example
    • Lead becomes qualified
    • Opportunity becomes approved
    • Account enters At Risk
    • RFQ arrives
    • Monthly review period starts
    ProducesTrigger / state definition

    Second-orderA trigger on “any change” runs on changes nobody meant as a business event

  2. Define the outcome
    Step 02 · The question

    What must be true when the automation finishes?

    Success is a business state, not an exit code.

    Define
    • Target state
    • Generated records
    • Notifications
    • Ownership
    • Audit evidence
    ProducesOutcome contract

    Second-orderWithout an outcome contract, “it ran” is the only thing anyone can check

  3. Separate rule from judgement
    Step 03 · The question

    What can be decided deterministically?

    Automate the rule; prepare—not replace—the judgement.

    Classify each step
    • Automated
    • Assisted
    • Human decision
    ProducesAutomation boundary

    Second-orderA human approval is not an automation failure; it is an intentional boundary

  4. Define state transitions
    Step 04 · The question

    What intermediate states exist?

    Model the run, not only the record.

    For example
    • Pending
    • Running
    • Waiting
    • Succeeded
    • Failed
    • Aborted
    • Retrying
    • Reconciled
    ProducesState machine

    Second-orderIf “waiting” is not a state, waiting looks like failure

  5. Define side effects
    Step 05 · The question

    What does each transition change?

    Every effect has one owner and one key.

    For example
    • Create task
    • Update status
    • Write KPI
    • Call external system
    • Notify owner
    • Add campaign member
    ProducesEffect map

    Second-orderTwo automations writing the same field is an ordering bug waiting to happen

  6. Design exception paths
    Step 06 · The question

    What happens when the happy path breaks?

    Classify first; not every failure is a retry.

    Define
    • Validation failure
    • Timeout
    • Duplicate
    • Missing owner
    • Partial completion
    • External outage
    • Stale state
    ProducesException model

    Second-orderAn email to an administrator is not an exception path

  7. Design idempotency and safe rerun
    Step 07 · The question

    What happens if the same automation starts twice?

    If a process can run twice, design it to run twice.

    Define
    • Deduplication key
    • Guard
    • Already-processed state
    • Retry behaviour
    • Replay behaviour
    ProducesExecution safety model

    Second-orderSafe reruns are architecture, not a bug fix

  8. Choose the execution pattern
    Step 08 · The question

    How should this run?

    Chosen from duration, dependencies and recovery—not from habit.

    Choose between
    • Synchronous transaction
    • Asynchronous job
    • Scheduled process
    • Queue and worker
    • State machine
    • Event-driven automation
    ProducesExecution architecture

    Second-orderA chain of workflows is not automatically an orchestrator

  9. Add observability
    Step 09 · The question

    Can we answer what started, what is running, waiting or failed—and who owns recovery?

    Observable as a business process, not only as logs.

    Answer
    • What started?
    • What is running?
    • What is waiting?
    • What failed?
    • Who owns recovery?
    • What changed?
    ProducesOperational telemetry model

    Second-orderSuccessful execution is not the same as a successful business outcome

  10. Govern the automation
    Step 10 · The question

    Who owns this after go-live?

    Automation is a product with an owner, not a project deliverable.

    Define
    • Technical owner
    • Business owner
    • Change process
    • Monitoring
    • SLA
    • Retirement conditions
    ProducesAutomation operating model

    Second-orderAutomation without an owner keeps running long after its rule stopped being true

03Typical problemsSymptoms, and what is usually missing

The symptoms arrive as “the flow didn’t fire”.

Or it fired twice, or half-way, or for a record that no longer qualified. Underneath, a state, a guard or an owner was never designed.

  • People route work by hand using rules everyone already knows.

    Usually missingA deterministic routing rule with an owner

  • Approvals stall because nothing escalates.

    Usually missingA decision clock and a next owner

  • Several automations update the same field in unpredictable order.

    Usually missingOne owner per field and an execution order

  • One failure leaves downstream records half-created.

    Usually missingA run record that knows which steps completed

  • Scheduled jobs overlap, and the same customer is processed twice.

    Usually missingA start-once guard and an idempotency key

  • Bulk processes fail halfway and restart from zero.

    Usually missingContinuation from the last completed batch

  • Automation state is visible only in technical logs.

    Usually missingRun status in business terms, for the business owner

  • Automation keeps acting on records that are no longer eligible.

    Usually missingEligibility guards and designed exits
04What I designTangible artefacts

Artefacts that make automation reliable after go-live.

Each one answers a question the first version of a flow usually leaves open.

DesignWhat should run, and when
  • Trigger modelWhich business state starts each automation—and which must not?
  • Workflow mapWhich steps, in which order, with which side effects?
  • Automation boundaryWhat is automated, assisted or left to a person?
  • State machineWhich states exist, which transitions are valid, which are terminal?
  • Approval architectureWhich decisions, which evidence, what invalidates an approval?
ExecutionHow it runs safely
  • Orchestration designWhich runs span systems and wait—and who coordinates them?
  • Execution guardWhat stops the same run starting twice?
  • Idempotency designWhy can a step repeat without repeating its effect?
  • Retry & replay strategyWhich failures retry, which resume, which stop?
  • Schedule architectureWhen runs start, how they continue, and what if one is missed?
  • Exception modelHow each class of failure is detected, owned and recovered.
OperationWho sees it and owns it
  • Escalation modelWho is told when work waits too long—and then who?
  • Run historyWhat ran, when, on what, with which result?
  • Observability dashboardWhat is running, waiting or failed—in business terms?
  • Automation ownership modelBusiness owner, technical owner, change and retirement.
05Automation boundaryHuman · assisted · automated · orchestrated

Automate the coordination. Keep the judgement visible.

Every step sits somewhere between a person deciding and systems coordinating. The position is a design decision—with its own accountability and its own idea of failure.

Human

Judgement, accountability or consequences that are hard to reverse.

Examples
  • Commercial negotiation
  • Approving a deviation from policy
  • Confirming a probable duplicate
Accountability
The person who decides—named, with the evidence they used.
Failure expectation
Expected and designed for: “no” and “not yet” are outcomes, with a clock and an escalation.
Assisted

A person decides; the system prepares the decision.

Examples
  • Recommend the next action
  • Assemble approval evidence
  • Propose account matches
Accountability
The person who accepts or overrides the suggestion.
Failure expectation
A wrong suggestion is caught by the person; overrides are recorded and reviewed.
Automated

Deterministic, frequent and reversible within one system.

Examples
  • Route a lead
  • Create a follow-up task
  • Send an SLA reminder
Accountability
The business owner of the rule; the platform team for its execution.
Failure expectation
Rare and local. Fails visibly on the record, never silently.
Orchestrated

Stateful and cross-system: several steps, waits and dependencies.

Examples
  • Create a customer across CRM and ERP
  • Run the monthly performance cycle
  • Coordinate CRM, data and follow-up
Accountability
A named run owner, plus an owner per step’s system.
Failure expectation
Normal. Timeouts, partial completion and outages are designed states with recovery.

A human approval is not an automation failure. It is an intentional boundary: a designed wait, with a clock, an owner and an escalation.

Where the boundary starts: Process Architecture

06Workflow vs orchestrationLocal rule or stateful run

A chain of workflows is not an orchestrator.

Workflows react to a trigger with a local action. Orchestration owns a run across steps, systems and waits—and knows how to resume it. Complex coordination built as a chain of triggers fails without anyone knowing where.

Workflow
  1. Trigger
  2. Rule
  3. Action
Best for
  • A local process
  • Limited side effects
  • Short-running behaviour
  • Simple recovery
Orchestration
  1. State
  2. Step
  3. External dependency
  4. Wait
  5. Resume
  6. Branch
  7. Recover
Best for
  • Multi-step processes
  • Cross-system work
  • Long-running runs
  • Recoverable steps
  • External dependencies

ScenarioActivate a new customer: create in the ERP, wait for validation, assign the price list, create onboarding tasks, notify the account team.

Each step is a separate trigger reacting to the previous step’s side effect.

  1. 01Create in ERPCommitted, untracked
  2. 02Wait for validationCommitted, untracked
  3. 03Assign price listFailed
  4. 04Create onboarding tasksNever fires
  5. 05Notify account teamNever fires
Where did it stop?
Unknown: no record of the run, only records that changed.
Steps 1 and 2
Committed. Nobody knows they belong to an unfinished activation.
Step 3 failure
An email to an administrator; steps 4 and 5 never fire.
Recovery
Someone edits the record to re-trigger the chain—and step 1 runs again.
07Run state machineValid transitions · terminal states

If a process can run twice, design it to run twice.

A long-running automation is a run with a state. Waiting is a state, not a failure; failure has two kinds; recovery has three moves. Select a state to see where it can go—and who moves it.

Run path
Failure
Recovery
Run path

Waiting external

A request left for another system or a person. The run is paused, not stuck: it has a wait budget.

Can move to
  • ReadyThe outcome arrivesExternal
  • ReconcileNo answer within the wait budgetTimer

Entered from Running.

08Exception & recoveryDetect · classify · own · recover · reconcile

Not every failure is a retry.

Each class of failure is detected differently, owned by someone different and recovered differently. Retrying a validation failure or a business rejection only repeats it.

Class of failure

ExampleTimeout, lock or rate limit

  1. 01 · Detect

    Error class from the platform or service

  2. 02 · Classify

    Transient

  3. 03 · Own

    Automation (then platform team)

  4. 04 · Recover

    Retry with backoff and the same key, within a budget

  5. 05 · Reconcile

    Exhausted retries become final failures with an owner

RetryRetrying helps here—with the same key, a backoff and a budget.

09Scheduled & recurring automationRuns, not timers

A schedule proposes a run. It does not run the work.

Recurring automation is where overlap, missed periods, dependencies and long-running continuation meet. The pattern turns a timer into an identifiable, resumable run.

  1. 01Schedule

    A clock proposes a run. It does not execute the work itself.

  2. 02Run record

    One record per period: key, inputs, owner, dry-run flag. A second start for the same key is refused.

  3. 03State machine

    The run moves through declared states; each step records its outcome.

  4. 04Work queue

    The population is split into batches, each with its own status.

  5. 05Continuation

    Each batch schedules the next, so long work never hits a time limit and resumes where it stopped.

  6. 06Finalization

    Verify completeness, reconcile, publish the result and close the run.

Questions every recurring automation must answer

  • 01Exact time or eventual execution?

    Almost always eventual: “after the data refresh, on the first working day” beats “at 02:00”. The run waits for its dependency, not for the clock.

  • 02Which timezone?

    The business calendar’s, declared on the schedule. Month-end in one region is still the previous day in another.

  • 03What if the previous run is still active?

    The new run is refused or queued behind it—never started in parallel on the same key.

  • 04How is overlap prevented?

    A start-once guard on the run key (for example period + scope), checked atomically when the run is created.

  • 05How are missed runs recovered?

    The schedule looks for periods without a completed run and proposes them, oldest first.

  • 06How are external refreshes handled?

    As an explicit waiting state with a budget: the run waits for “data refreshed for period”, then continues or escalates.

  • 07Monthly vs daily cadence?

    The period is part of the run key. Daily and monthly runs are different run types with different keys and owners.

  • 08How does long-running work continue?

    Batches with continuations and a cursor, so a limit or a restart resumes from the last completed batch.

10ObservabilityBusiness progress, not only logs

Successful execution ≠ successful business outcome.

Automation should be observable as a business process: what started, what is running, what is waiting, what failed, who owns recovery and what changed.

One run, as the business owner sees it

Run view · synthetic

Monthly performance run

Run ID
R-2026-09
Started at
1 Oct · 06:10 (business calendar)
Current state
Waiting external
Current step
5 of 8 · CRM writeback
Records processed
3,420 of 3,510 accounts
Failures
12 · 9 retrying, 3 with owner
Next action
Resume batch 18 after the service window
Owner
Commercial operations
  1. 01 · Data refreshDone
  2. 02 · KPI computationDone
  3. 03 · ClassificationDone
  4. 04 · Segment activationDone
  5. 05 · CRM writebackWaiting
  6. 06 · Action generationPending
  7. 07 · ReconciliationPending
  8. 08 · FinalizationPending

Technical execution vs business progress

  • Technical execution: Job finished with status 0Business progress: Accounts classified; 90 still missing a target
  • Technical execution: Flow interview completedBusiness progress: Customer activated; onboarding tasks created for the owner
  • Technical execution: Batch 17 of 36 succeededBusiness progress: CRM writeback 47 % complete; resumes after the service window
  • Technical execution: Unhandled fault email sentBusiness progress: Price-list step failed for one customer; pricing owner assigned
  • Technical execution: Scheduled job skippedBusiness progress: September run not started: the data refresh has not finished
11Reference casesFictional & composite

Six automations, six execution problems.

Synthetic global B2B scenarios. Where a process or data case already tells the story, these take only the execution lens and link back.

  1. Case 01Selected workRun record, state machine & safe resume

    Designing a monthly commercial performance orchestrator

    A monthly process with eight dependent steps runs as one scheduled job—so any failure means starting again, and some accounts get their actions twice.

    Architecture questionHow is one monthly run identified, resumed and finished—exactly once?

    ⟲ resume hereRefreshORCHKPIsAUTOClassifyAUTOWrite backORCHActionsAUTOFinalizeHUMAN
    SchedulerData platformCRMCampaign platformConnects toData & IntegrationsRevenue Operations
  2. Case 02Entries, exits & deduplicated actions

    Automating commercial actions from performance segmentation

    A segment change creates tasks and campaign memberships—but nothing removes them when the account recovers or leaves the population.

    Architecture questionHow does a segment become exactly the right actions—and stop being them when it changes?

    SegmentAUTOEligible?AUTOCampaignAUTOTaskAUTOPlanHUMAN
    CRMCampaign platformData platformConnects toRevenue OperationsData & Integrations
  3. Case 03Inferred, explicit & validated input

    Designing guided visit creation without hiding the process

    Logging a customer visit takes six screens—so sellers skip it, or create duplicates with half the context.

    Architecture questionWhat can automation infer, and what must the seller still decide explicitly?

    ContextAUTOPurposeHUMANValidateAUTOCreateORCHFollow-upsASSIST
    CRMCalendarConnects toChange & AdoptionRevenue Operations
  4. Case 04Deterministic routing & designed uncertainty

    Automating inbound lead validation and routing

    Routing rules are clear for most leads—but ambiguous geography, existing customers and missing owners make the automation guess.

    Architecture questionWhich routing decisions are deterministic, and where must the automation stop and ask?

    ⟲ when unsureValidateAUTODedupeAUTOGeographyAUTOSubsidiaryAUTOAssignAUTOReviewHUMAN
    WebsiteCRMMarketing automationConnects toProcess ArchitectureRevenue Operations
  5. Case 05Approval states, invalidation & re-entry

    Designing approval automation as a state machine

    Approvals are a chain of emails: nobody knows which decision is pending, rejected quotes come back as edits, and changed prices keep old approvals.

    Architecture questionWhich changes invalidate an approval—and where must the process restart?

    ⟲ returned → resubmitSubmitHUMANCommercialHUMANRouteAUTOFinancialHUMANApprovedAUTO
    CRMERPNotificationConnects toProcess ArchitectureDigital Operating Model
  6. Case 06Automated cleanup with guardrails

    Designing a reconciler for stale downstream state

    Upstream eligibility changes, but campaign memberships, tasks and recovery processes stay behind—and cleaning them up is a quarterly manual job.

    Architecture questionHow does an automation close what should no longer exist—safely, and without closing real work?

    ⟲ next runExpectedAUTOCompareAUTOClassifyAUTOActORCHReviewHUMAN
    CRMCampaign platformData platformConnects toData & IntegrationsRevenue Operations

All automation cases in the architecture library

12Questions that change the designThe second layer

Every automation request has a second layer.

The visible request is where the design starts, not where it ends.

Start from a request
Visible requirement
“Automate the approval.”
First layer

Add an approval step that emails the manager.

That is a notification. It is not yet an approval architecture.

4 of 6 questions surfaced

Second layer — what the request leaves unsaid

  1. Commercial approval and financial validation have different evidence and SLAs.

13Connected capabilitiesWhere automation sits

Process defines it. Systems host it. Automation executes it.

Automation

  1. Process Architecture

    The process defines the states, decisions and exceptions; automation executes the deterministic part of it.

  2. Systems & CRM Architecture

    Systems decide which platform owns each step; automation runs inside—or across—those boundaries.

  3. Data & Integrations

    Integrations move and reconcile state; automation acts on it, once, when a rule says so.

  4. Revenue Operations

    Signals like At Risk or low coverage become tasks, campaigns and escalations—automatically and with exits.

  5. AI & Agentic Workflows

    Agents are automation with judgement at the edge; they need the same states, guards and review points.

  6. Digital Operating Model

    Every automation needs a business owner, a technical owner and a change process.

Next capability · 07AI & Agentic Workflows

Reliable automation is not a faster click. It is process execution with

  1. Triggers
  2. Rules
  3. Human decisions
  4. State
  5. Idempotency
  6. Exceptions
  7. Recovery
  8. Visibility
  9. Ownership

Reliable automation starts where the happy path ends.

Automate the coordination. Keep the judgement—and the state—visible.

Start with the run

Automation that works—until the day it doesn’t?

  • What happens if it starts twice?
  • Where does a failed run stop—and who resumes it?
  • Which actions are never removed?
Start a conversation