Use code at orchestration boundaries
Keep transparent local rules declarative; move stateful, cross-system orchestration behind tested service boundaries.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01Context
A multi-step commercial process mixes approvals, external API calls, retryable work and user-facing automation.
02Decision drivers
- D01
Testability
- D02
Failure isolation
- D03
Change ownership
- D04
Transaction boundaries
03Options considered
Declarative only
Local deterministic record rules
Cost: Opaque failure at scaleCustom only
Complex state machines
Cost: Higher delivery overheadDeliberate hybrid
Clear bounded responsibilities
Cost: Needs governance04Decision
Use declarative automation for local, inspectable rules. Invoke a coded orchestration boundary for multi-system state, idempotency, retries and compensation.
05Consequences
- Ownership is defined by boundary, not developer preference.
- Automations cannot directly chain unmanaged external side effects.
- The service publishes observable states back to the user workflow.
06Revisit when
The process becomes local and deterministic.
Platform-native orchestration gains equivalent testing and recovery controls.
07Where this decision is applied
Cases that take this decision, and why it matters there.
- Process case / 02Designing a quote-to-order process with clear ownershipBinding approvals to quote versions, moving ERP validation forward and giving rejected orders an owner.
- Process case / 04Designing an RFQ intake process before introducing AIDefining the RFQ intake process—definitions, ownership, validation—before an AI agent runs any of it.
- Data case / 03Writing analytical signals back into operational CRMA writeback contract for derived KPIs and segments: account grain, read-only in the CRM, stamped with freshness and version, reconciled against what was published—and turned into exactly one task per signal.
- Automation case / 01Designing a monthly commercial performance orchestratorOne run record per period with a state machine, start-once guards, continuations per batch and a reconciliation before finalization—so a failure at step four resumes at step four.
- Automation case / 03Designing guided visit creation without hiding the processA guided creator that prefills context, asks only for what needs judgement, validates relationships, and creates the visit and its follow-ups as one resumable action.
- Operating-model case / 05Governing operating-model change after go-liveThe operating model as a product: change requests classified by domain, decided by named owners with evidence and time limits, released in versions—so the model keeps improving after the project ends.
- Adoption case / 06Keeping adoption owned after the project team leavesA rollout that ended at go-live: responsibilities handed from project roles to named operating owners, a friction register feeding one governed backlog, a release cadence, and adoption signals reviewed on a schedule—so the design keeps improving.