Separate evidence, decision and execution
A workflow often begins with an observation, such as an inventory shortage or an overdue receivable. That observation is evidence, not an instruction. A decision interprets the evidence under business rules and authority constraints. Execution then changes a system or initiates work. Keeping these stages distinct makes it easier to review why an action was proposed and whether it was actually completed.
Represent each stage with an identifiable record. Capture the evidence used, the decision outcome and the execution status separately. A recommendation may be rejected, expire before approval or fail during execution. Treating all of these as one generic workflow status obscures both user expectations and the information an operator needs to recover safely.
Make business rules inspectable
Business rules can depend on thresholds, calendars, contractual terms and organisational roles. State the inputs and expected outputs explicitly, then version the rule definition. OMG’s Decision Model and Notation provides a standard for modeling decisions, while Business Process Model and Notation describes process behavior. These standards can help teams separate decision logic from the sequence of tasks that surrounds it.
Do not hide consequential policy choices in an unreviewed prompt or a collection of scattered conditionals. Maintain representative examples for normal, boundary and conflicting conditions. Have the business owner review what happens when required evidence is missing. The right result may be a request for more information rather than an automatic choice between incomplete alternatives.
Define who can approve which action
The ability to view evidence is different from authority to approve a change. Establish approval requirements according to the action, its scope and the user’s role. A person may be permitted to investigate a contract but unable to accept a commercial amendment. A service identity may be allowed to create an internal task while being prohibited from changing a financial record.
Evaluate authorization when the action is requested and again where execution crosses a trust boundary. OWASP’s authorization guidance emphasises access checks on every request and a default denial posture. Include separation of duties where required by the business process. Record the approver and applicable authority without assuming that a previous sign in grants indefinite permission to every future operation.
Recheck evidence before committing a change
A decision can become obsolete while waiting for approval. Inventory may arrive, an invoice may be settled or a customer may change an order. Record the source versions or conditions that justified the proposal and check them before execution. Define what happens if those preconditions no longer hold: cancel, recalculate or return the decision for review.
Use a concurrency mechanism appropriate to the target system where one is available. An expected record version or conditional request can help prevent overwriting a newer change. If the target cannot support such a check, document the remaining race and choose a narrower operation or human confirmation where needed. The interface should show that an approved proposal is still subject to execution conditions.
Design retries around business consequences
Execution can fail after the target system has accepted a request but before the workflow receives confirmation. A blind retry may duplicate the action. Preserve an operation identifier, inspect the target’s supported idempotency behavior and reconcile uncertain outcomes. A timeout should produce an unknown execution state until evidence establishes whether the action occurred.
Plan compensating actions where a process spans multiple systems, but do not assume that every business effect can be reversed. Sending an external notification and transferring a physical item have different recovery properties. Document which steps are retryable, which require investigation and which need a new approved action to compensate. Operators need this information before an incident occurs.