Approval Workflows
CDX approvals are a durable workflow family, not a graph template you rebuild in each app.
Canonical Definition
ApprovalWorkflowDefinition in cdx_workflow_templates is the durable source. It covers:
- zero-level auto-approval;
- single-level and multi-level chains;
- rejection, revision, resubmission, cancellation, and failure;
- domain dispatch through
item_schema_type; - typed start and effect contracts (
ApprovalStart,ApprovalEffectOutcome).
A legacy graph definition remains for in-flight ELOG and DocsIQ runs. Parity tests compare terminal status and domain effects across both authoring surfaces. Do not switch those products until the adoption gate passes.
Starting an Approval
Product APIs start the durable version through the workflow service with a typed start envelope. They do not call LegacyWorkflowEngine.startWorkflow for new versions.
Assignment is persisted on each user-task command. Completing an approval decision goes through completeUserTask with the registered response codec, not a graph signal port.
Domain Effects
Outcome handlers (onApproved, onRejected, onRevisionRequested, onCancelled, onFailed, onResubmitted) are versioned activities. They must be idempotent. They must not rethrow in a way that shadows the original workflow failure.
Inbox
cdx_feature_workflows renders the sealed UserTaskAction list produced by the server. Flutter does not reconstruct approval routing.