A supplier onboarding request starts with a submitted form, waits for a document check, requires an internal approval and finally creates an account in another system. The process may last several days, while the web request that started it lasts only seconds. Keeping all of that progress in one running process would make ordinary restarts a business concern.
Durable Functions provides a way to model stateful workflows using Azure Functions. The platform handles aspects of durable execution, but the business still needs a clear state model, valid approval rules and a plan for external effects. The most useful design begins by explaining how the process should behave when people, services and time move at different speeds.
Draw the business states before the orchestration
List the stages a request can reach and the information needed to move between them. Include rejection, cancellation, expiration and manual review, not only the successful route. Give each state a meaning that operations staff can explain to the person waiting for the result.
For a hypothetical supplier-onboarding workflow, “documents received”, “review required”, “approved” and “account created” are different states. Approval does not prove that the external account exists. Record which system owns each fact and how the overall process discovers that a step completed.
Microsoft's Durable Functions overview describes stateful orchestration and supported application patterns. Use those capabilities to implement the chosen process rather than letting a sample workflow determine the business policy. Durable Functions overview.
Separate coordination from work with side effects
Keep the orchestration responsible for the sequence and state of the workflow. Place external calls and other side effects in the appropriate activity or integration boundary. This separation helps the team reason about which decisions may be replayed and which operations actually change another system.
Durable orchestration uses replay and imposes determinism constraints on orchestrator code. Microsoft's guidance explains restrictions around time, randomness and direct external work. Follow the APIs and rules for the selected language and runtime instead of treating an orchestrator as an ordinary long-running method. Durable code constraints.
For supplier onboarding, make document validation and external account creation explicit operations with useful outcomes. Return business-relevant states such as accepted, rejected or unresolved. Avoid making the orchestration guess whether an external action succeeded from a generic message intended only for a developer's log.
Make waiting and deadlines explicit
Define how a workflow waits for human input or an external event and how long that wait may last. An approval deadline, a reminder and an expiry decision are different events. Use durable waiting mechanisms suitable for the framework rather than holding a thread or keeping an HTTP request open.
Bind the response to the correct workflow instance and proposal version. Verify the identity and authority of the person supplying an approval through the application's normal boundary. The existence of a workflow event endpoint does not itself establish that a caller may approve the underlying business action.
Specify what happens to late responses. If a request expires and is resubmitted, an old approval should not casually advance the new process. Present current state to the reviewer and make rejection or revalidation understandable. These rules belong in acceptance tests because timing problems are difficult to discover through an idealised demonstration.
Protect external effects from repeated attempts
Activities and integration calls can encounter failures whose outcomes are uncertain. Design important external operations to recognise the same business request across retries. A workflow resuming after a problem should not create another supplier account merely because it cannot see the first response.
Use a stable operation reference and a way to confirm the destination state where the external system supports it. If the destination cannot provide idempotent creation or reliable lookup, define the point at which the workflow pauses for investigation instead of repeatedly making an irreversible request.
Plan compensation in business terms. Deactivating an incorrectly created account may be possible, while reversing a notification already read by a supplier is not. Document which effects can be undone, which require a corrective action and which remain part of the history even when the overall workflow fails.
Design changes for workflows already in progress
A deployment can occur while requests are waiting for approval. Decide how those existing instances continue when orchestration logic or activity contracts change. Review the framework's versioning options and compatibility requirements for the runtime being used, and rehearse a representative upgrade with in-flight work.
Keep long-lived business data and references understandable across versions. A new required field may not exist in an older request, so define whether it can be derived, requested from a user or handled by the earlier path. Avoid discovering that incompatibility only when an approval arrives several days after release.
Maintain an inventory of active workflow states during significant changes. Operations should know how many requests are affected and what support action might be needed. This turns versioning into an observable release concern instead of an assumption that every process starts and finishes under the same application build.
Give operations a useful view of progress
Expose the current business state, elapsed time and next responsible action through an authorised interface. A raw orchestration identifier is useful for diagnostics, but it does not tell a supplier manager why a request is still waiting. Connect technical state to the decision the business needs to make.
Create controlled procedures for cancellation, retry and manual resolution. Each should check the current state and the effects already applied. Record why an intervention occurred, and avoid treating a dashboard button as permission to repeat every activity indiscriminately.
Worktechlabs can help design Azure workflow integrations that survive delays and restarts while preserving business control. Combine durable orchestration with reliable message handling and explicit approval boundaries so people can understand what has happened, what is waiting and how the process will recover.
Official sources and further reading
- Microsoft: Durable Functions overview — stateful workflow capabilities and patterns.
- Microsoft: durable orchestrator constraints — replay and deterministic execution requirements.
