Integration Platforms
Part of Stateful workflow orchestration
Handling long-running approvals across systems
Design a durable approval request, callback and deadline so a delayed decision safely continues work across systems.
Treat a long-running approval as a durable request with an identity, a deadline and a rule for continuing after a decision. The response must reach the right workflow instance, come from an authorised decision path and still apply to the business record. A callback arriving days later does not establish that the record is unchanged.
Create a durable approval request
Tie the approval request to a business-record ID and the version or snapshot under review. Record the workflow instance, requested decision, approver route, deadline and status.
The business application owns the underlying request; the approval record establishes what was put to the approver. A message or email is a delivery channel, not the sole record of a pending decision.
For an equipment purchase, the purchasing application might own the amount and supplier while the workflow waits for a decision on a specified request version. Make ownership of the approval record explicit in the design.
Handle the response
The approval service should return the request ID, a decision ID and the decision through an authenticated, authorised route. Check the expected workflow stage and whether that decision ID has already been processed. A repeated delivery should return or retain the earlier result without advancing the instance twice. Do not assume a workflow event's arrival proves the sender was entitled to approve.
Durable runtimes offer different return paths. Microsoft Durable Task can wait for an external event; its documentation describes external events as one-way asynchronous operations.
An AWS Step Functions callback task can wait for a task token in a supported Standard Workflow integration; Express Workflows do not support that callback pattern. The workflow design must also fit the selected product's execution and timeout limits.
Record the accepted decision before attempting the next business action. Keep the destination result ID when the action succeeds. If submission times out, check the destination before sending another request.
Durable Task Runtimes: External Event Support
- Microsoft Durable TaskSupports external events as one-way asynchronous operations; waits for event via durable runtime.
- AWS Step Functions (Standard)Supports callback tasks using task tokens; requires integration setup.
- AWS Step Functions (Express)Does not support callback pattern; suitable only for short-lived workflows.
- Temporal.ioUses message passing for workflow coordination; supports async callbacks and event-driven logic.
Define expiry and changed-record rules
Set a deadline and decide whether it triggers a reminder, escalation, rejection or manual review. Specify how a decision received after expiry is handled; it should not silently reopen a closed request. Displaying the deadline in the business interface helps people understand what is pending.
Before acting on an approval, compare the reviewed version or relevant snapshot with the current business record. If a material field changed, follow the defined rule for reapproval, cancellation or manual review. The workflow should not infer which changes are acceptable.
Review the complete path for approval, rejection, no response, a repeated or late decision, and a changed record. For each case, the workflow stage and destination record should tell the same story. An operator should be able to identify the request, its deadline, the accepted decision and the last confirmed external action.
