Review a customer case through evidence and human decisions
Status: Upcoming — not yet available.
Section: DOC-WF-process-management#overview.
Handle a customer case that needs two pieces of evidence and an authorized human decision before closure. People and agents work on assigned tasks, and the case shows what is complete, missing or still uncertain.
Use a case when new evidence can open or repeat activities; use a fixed process for the final approval sequence. You need authorized source records, reviewed task definitions, eligible reviewers, deadlines and the owning record that confirms the outcome.
The process, case, task-inbox and comparison interfaces are not yet available. This recipe describes the completed-product experience and provides no current start commands.
Step 1: choose the case and its fixed approval process
Status: Upcoming — not yet available.
Section: DOC-WF-process-management#process-or-case.
Represent the customer's review as a case with evidence-gathering activities and milestones. Let new evidence make the relevant activity eligible again. Use a child process for the fixed sequence that validates the packet, requests approval and records the result.
If the whole job has a known sequence with no changing activities, use a process directly instead. Processes describe reviewed tasks, decisions, waits and outcomes; cases organize changing work around a subject.
Keep the source documents and customer records in their owning systems. The case references them and tracks progress without becoming another private-data store or a billing authority.
Step 2: define the evidence tasks and start the case
Status: Upcoming — not yet available.
Section: DOC-WF-process-management#model-preparation.
- Name the customer outcome and organization/project/environment/customer scope.
- Select reviewed immutable task definitions for each evidence check. Set inputs, expected outputs, eligible assignees, deadlines and failure paths.
- Define what happens when evidence is missing or invalid, retaining the decision-rule version and evidence behind each branch.
- Bound agent work, parallel branches and revision loops. Require both checks for a complete packet, and define the partial-result path when one fails.
- Specify the exact proposal/form revision and authority for the final human decision.
- Set recurring starts and deadlines through one scheduling owner. A retry keeps the original deadline.
- Review the model, start the case and follow the two evidence tasks.
The model and its schema/decision contracts remain inspectable without requiring a visual editor. If one evidence branch fails, the join names the missing evidence and follows the failure path rather than presenting a complete packet.
Step 3: claim the review and decide on the current evidence
Status: Upcoming — not yet available.
Section: DOC-WF-process-management#human-task-review.
Open the task and inspect its occurrence, assignment, deadline, model/form revision and affected resources. Claim only work you are eligible to perform, read the exact proposal and submit your decision.
If another person claims it or the form/evidence changes, refresh and resolve the conflict before deciding. Approval stays within the reviewer's access and original task limits. Reassignment requires an eligible recipient; a recurring case activity is a new occurrence with its own result.
After the decision, follow the case to its owning record and confirmed outcome. Finished result: the case identifies the evidence used, authorized decision and final record. Missing evidence, a pending reviewer or an uncertain external action leaves the case incomplete rather than silently closing it.
Recover a missing branch, deadline or uncertain external action
Status: Upcoming — not yet available.
Section: DOC-WF-process-management#run-outcomes.
Inspect business completion, task failure, cancellation, deadline expiry and uncertain remote outcomes separately. A task timing out after an external request may still need reconciliation. A joined result identifies unsuccessful branches and useful partial output.
Use the model version, current task occurrence, input/output revisions, decision evidence, operation references and observation time to understand what happened. Lists, details and exports retain the same customer scope; an empty page does not establish that no other records exist.
Reconcile the original external operation before retrying an action that may have completed. Duplicate events recover the same intent, and older updates cannot reverse a newer accepted case state. Cancel, suspend, resume and delete have different effects; inspect already-dispatched work separately from actions stopped by the lifecycle change.
Variant: compare a revised review process before using it
Status: Upcoming — not yet available.
Section: DOC-WF-process-management#comparison-and-promotion.
Use the same immutable case samples and reference labels for the baseline and candidate. Select the exact output field and schema to assess; keep human labels separate from automated grader judgments.
Run both versions, then compare quality, missing-result coverage, safety, latency and cost. Keep excluded or unfinished samples and undefined metrics visible. For example, a candidate that improves review quality while increasing cost needs both results considered.
Promote only through an authorized decision for the reviewed scope. Finished result: the team can decide from comparable completed and incomplete evidence. An inconclusive comparison or confident model judgment does not approve the change automatically.
Upgrade or restore while cases still have pending work
Status: Upcoming — not yet available.
Section: DOC-WF-process-management#process-recovery.
Before upgrading, review active model versions, pending tasks and approvals, deadlines, delayed events and unresolved external operations. Choose the supported continuation, explicit migration or finish-before-upgrade path for active cases. A new definition does not silently reinterpret a running case.
A pending decision stays tied to its reviewed version. After restore, current access and deletion restrictions apply before data is served or work starts. Keep run references and use the operating channel for unresolved outcomes; retained history continues to show unfinished work.
Recovered result: each active case has an understood version and continuation path, with unresolved operations still visible. See agent coordination, deployment operations and Workflows for related recipes.
Document ID: DOC-WF-process-management. Section identities and revisions.