Skip to content

Workflow hand-off and completion

Detect an authoritative approval or state-change event and carry low-risk downstream closure work through to completion with idempotent updates, verification, and audit-ready traces.

Metadata

  • Pattern id: workflow-hand-off-and-completion
  • Pattern family: Execute / Automate
  • Problem structure: Approval-gated execution (approval-gated-execution)
  • Domains: Research (research), Engineering (engineering), HR (hr), Compliance (compliance), Support (support)

Workflow goal

Observe a trusted upstream approval, disposition, or completion-state transition and finish the allowed downstream closure steps across operational systems without reopening the decision itself or crossing into higher-risk execution.

Inputs

Authoritative upstream state-change record

  • Description: A trusted event or record showing that an approval, accepted disposition, or completion decision has already been made in the source-of-truth system.
  • Kind: decision-record
  • Required: Yes
  • Examples:
  • Publication-review board marks a benchmark study approved for internal catalog closure
  • Release-readiness review marks a version accepted and ready for scheduler handoff

Downstream completion policy and mapping

  • Description: Rules that define which low-risk completion actions are allowed, which systems should be updated, and which conditions require manual follow-up instead of automatic propagation.
  • Kind: policy
  • Required: Yes
  • Examples:
  • Rule mapping an approved review disposition to tracker closure, evidence archiving, and notification steps
  • Idempotent completion policy that forbids any action beyond status sync, archive linkage, and queue cleanup

Linked workflow context

  • Description: Case identifiers, record links, evidence references, ownership metadata, and target-system pointers needed to propagate the approved state correctly.
  • Kind: workflow-context
  • Required: Yes
  • Examples:
  • Study identifier, review packet hash, catalog record id, and owner list
  • Release checklist id, change record link, milestone id, and evidence bundle location

Prior downstream completion state

  • Description: Existing target-state markers that show whether some or all completion steps already ran and therefore must be resumed idempotently or skipped.
  • Kind: completion-state
  • Required: No
  • Examples:
  • Existing archive link already written to the review record
  • Tracker task previously closed while notification delivery remained pending

Outputs

Completed downstream records

  • Description: Updated low-risk system records showing that the approved workflow moved into its intended closed, archived, or handed-off state.
  • Kind: completion-record
  • Required: Yes
  • Examples:
  • Research review item marked closed with approved-catalog status and archived evidence references
  • Release-readiness checklist closed with scheduler-handoff link and final evidence location

Completion audit trail

  • Description: Ordered trace of the triggering event, policy version, verification checks, downstream updates, skipped idempotent actions, and final state confirmations.
  • Kind: audit-log
  • Required: Yes
  • Examples:
  • Log showing approval event receipt, state recheck, registry update, archive write, and notification dispatch
  • Replay-safe trace proving that duplicate events did not create duplicate closure actions

Manual follow-up packet

  • Description: Structured handoff when the trigger is stale, the target state is ambiguous, or the requested completion path would exceed low-risk bookkeeping scope.
  • Kind: follow-up-record
  • Required: No
  • Examples:
  • Packet noting that the study disposition changed after the event fired and needs human reconciliation
  • Follow-up record for a missing release milestone mapping that prevented safe completion

Environment

Operates in governed workflows where consequential approval or decision making already happened upstream, and the remaining work is low-risk downstream closure, state synchronization, evidence archiving, or notification across a small set of operational systems.

Systems

  • Workflow, review, or case-management system that emits authoritative state changes
  • Tracker, registry, or system-of-record updated during downstream closure
  • Document archive or evidence store
  • Notification or queueing system for completion follow-through

Actors

  • Workflow owner
  • Reviewing or approving body that created the upstream state change
  • Operations or program coordinator who maintains closure rules
  • Auditor or process steward

Constraints

  • Perform only low-risk, reversible downstream updates that do not reopen or reinterpret the upstream decision.
  • Recheck the authoritative source state before writing to target systems so stale or revoked approvals are not propagated.
  • Keep completion idempotent across duplicate events, retries, or partial reruns.
  • Stop when required target mappings, archive references, or closure conditions are ambiguous enough to need human interpretation.

Assumptions

  • An authoritative source system publishes or exposes the approval or completion state that should trigger downstream work.
  • Downstream actions are limited to bookkeeping, handoff, closure, archival, or notification steps that are inexpensive to correct.
  • Humans remain available to resolve stale state, mapping drift, or any request to extend the workflow into new consequential actions.

Capability requirements

  • Monitoring (monitoring): The workflow must watch for authoritative approval or completion-state changes and react quickly when the relevant event arrives.
  • Tool use (tool-use): Completing the handoff requires writing to trackers, archives, registries, and notification systems rather than merely reporting that an event occurred.
  • Action execution (action-execution): The pattern creates real downstream state changes by closing records, attaching approved evidence, or advancing the work into its final low-risk completion state.
  • Verification (verification): The workflow must confirm that the trigger is still authoritative and that each target system reflects the intended end state before marking completion done.
  • Memory and state tracking (memory-and-state-tracking): Durable state is required to handle duplicate events, partial completion, replay-safe recovery, and audit-ready reconstruction of what happened.
  • Policy and constraint checking (policy-and-constraint-checking): Guardrails determine which downstream actions are allowed to run automatically and which mismatches must be routed to manual follow-up.

Execution architecture

  • Event-driven monitoring (event-driven-monitoring): The workflow is naturally triggered by an approval, accepted disposition, or state-change event and then performs a bounded closure sequence only when that signal is detected and revalidated.

Autonomy profile

  • Level: Autonomous with audit (autonomous-with-audit)
  • Reversibility: Most actions in this pattern are lightweight status syncs, archive links, queue cleanups, and notifications that can be corrected or replayed without material external consequence.
  • Escalation: Escalate when the authoritative source state is stale or conflicting, a duplicate event creates ambiguous target status, required target mappings are missing, or any requested action would cross from low-risk completion into a new operational commitment.

Human checkpoints

  • Humans define which upstream states authorize automatic completion and which downstream targets stay in scope for low-risk propagation.
  • Process owners review sampled completion runs, rule changes, and drift between source and target systems to confirm the workflow remains bounded and trustworthy.
  • Humans take over when approvals are revoked, mappings are missing, or the requested next step would extend beyond bookkeeping and handoff into new consequential execution.

Risk and governance

  • Risk level: Low (low)
  • Failure impact: Failures usually create localized record drift, delayed notifications, or incomplete closure bookkeeping that is visible and straightforward to correct before broader harm accumulates.
  • Auditability: Preserve the triggering event id and timestamp, source-state snapshot, policy version, target records touched, idempotency decisions, archive references, notifications sent, and any manual overrides so each completion run can be reconstructed.

Approval requirements

  • Automatic completion may run only after an authoritative upstream approval, accepted disposition, or completion-state transition is recorded and revalidated from the source-of-truth system.
  • Expanding the workflow to new target systems or less reversible actions requires human owner approval even if individual in-scope completion runs do not need case-by-case review.

Privacy

  • Propagate only the identifiers, status fields, and evidence references needed for downstream completion rather than copying whole review packets or sensitive narrative notes.
  • Keep notifications and logs focused on closure metadata so downstream bookkeeping does not leak unnecessary draft, participant, customer, or employee detail.

Security

  • Use least-privilege service accounts limited to approved closure targets and append-only audit stores where possible.
  • Require idempotent writes or conflict checks so duplicate events cannot silently create inconsistent completion state across systems.

Notes: Low-risk posture fits because the workflow acts only after an upstream decision already exists and is constrained to reversible downstream completion rather than new external commitments or sensitive submissions.

Why agentic

  • The workflow must detect and interpret live state transitions instead of running only on manual demand.
  • Safe completion depends on verifying authoritative state, applying bounded mappings, and choosing whether to continue or stop when targets do not align.
  • Durable memory and idempotent reasoning matter because duplicate events, partial completion, and replay are normal operational conditions.

Failure modes

Duplicate trigger events replay the same completion path twice

  • Impact: Downstream systems receive conflicting closure timestamps, repeated notifications, or duplicate archive links that need cleanup.
  • Severity: medium
  • Detectability: high
  • Mitigations:
  • Use idempotency keys tied to the authoritative source event and target record.
  • Re-read downstream state before each write and skip already completed steps explicitly.

A stale or superseded approval event is propagated after the source disposition changed

  • Impact: Records are closed or handed off using an outdated decision state and must be reopened manually.
  • Severity: medium
  • Detectability: medium
  • Mitigations:
  • Revalidate the source-of-truth disposition immediately before downstream updates.
  • Stop and emit a manual follow-up packet when the current source state differs from the triggering event.

Target-system mapping drift routes the approved state to the wrong record or milestone

  • Impact: Closure bookkeeping lands in the wrong place, creating localized confusion and manual rework.
  • Severity: low
  • Detectability: medium
  • Mitigations:
  • Validate target identifiers against current workflow context before writing.
  • Route unmapped or conflicting identifiers to manual follow-up rather than guessing.

Completion is marked done before archive or notification side effects are confirmed

  • Impact: The workflow appears closed even though downstream stakeholders or evidence stores never received the expected handoff artifacts.
  • Severity: low
  • Detectability: medium
  • Mitigations:
  • Require explicit confirmation for each downstream target before final completion status is emitted.
  • Store partial-completion state and resume only the unfinished steps on replay.

Evaluation

Success metrics

  • Percentage of approved workflow state changes propagated to all in-scope downstream systems without manual cleanup.
  • Rate of duplicate, stale, or unmapped trigger events safely suppressed or routed to follow-up before incorrect closure occurs.
  • Percentage of completion runs with full audit traces linking the source event to every downstream update.

Quality criteria

  • The workflow never reinterprets the upstream decision and stays bounded to low-risk closure, archival, and handoff actions.
  • Completion records distinguish clearly between fully completed, partially completed, skipped-as-idempotent, and manual-follow-up outcomes.
  • Replay or duplicate delivery does not create conflicting downstream closure state.

Robustness checks

  • Test duplicate event delivery and verify the workflow produces one coherent completion result without duplicate writes.
  • Test revoked or superseded approval states and ensure downstream updates stop after source revalidation fails.
  • Test missing archive links, stale milestone mappings, and partial target outages to confirm the workflow records partial state and escalates cleanly.

Benchmark notes: Evaluate correctness of source-to-target state propagation and replay safety together; fast closure is not valuable if the workflow hides stale approvals or creates drift across bookkeeping systems.

Implementation notes

Orchestration notes

  • Separate event intake, source revalidation, target update planning, execution, and completion confirmation into explicit stages over shared durable state.
  • Make idempotency decisions and partial-completion markers inspectable workflow data rather than implicit side effects in tool logs.

Integration notes

  • Common implementations integrate workflow systems, registries, archives, and notification channels through event subscriptions or queue consumers.
  • Keep the pattern neutral about specific workflow engines, ticketing tools, registries, or message buses.

Deployment notes

  • Start with narrow post-approval closure flows where the allowed target updates are already standardized and inexpensive to correct.
  • Review mapping drift, duplicate-trigger behavior, and audit completeness early before widening the catalog of completion rules.

References

Example domains

  • Research (research): After a benchmark-study review board records an approved disposition, update the internal study registry, archive the final review packet, and close the intake record automatically.
  • Engineering (engineering): After a release-readiness decision is marked accepted, close the checklist, sync the release tracker, attach evidence links, and hand the package to the scheduler queue without deploying anything.
  • HR (hr): After an occupational-health or leave-program review records an accepted disposition, close the restricted review queue, sync the leave case tracker, attach archive references, and notify the internal HR coordinator that review closure is complete without taking any employee-facing action.
  • Compliance (compliance): After a sanctions review system records a final false-positive disposition, close the restricted closure queue, sync the case ledger, attach archive references, and notify the internal sanctions operations coordinator without changing any live controls or taking external action.
  • Support (support): After an internal enterprise support case-review system records a final closure-approved disposition, close the restricted review queue, sync the escalation tracker, attach archive references, and notify the internal support operations coordinator without contacting the customer or executing any remediation.
  • Browser-based form completion with approval gates (contrasts-with)
  • Both patterns follow an approved workflow state, but this one is limited to low-risk downstream closure and bookkeeping rather than high-control browser submission.
  • Exception-aware task execution (adjacent-to)
  • This pattern handles event-triggered completion and idempotent handoff, while exception-aware task execution centers on resilient delegated operations with retries and escalations.

Grounded instances

Canonical source

  • data/patterns/execute-automate/workflow-hand-off-and-completion.yaml