# From Isolated Automation to Reliable Processes > Why a workflow is only as dependable as its ability to handle a change of plans. **Source:** https://pilot.isp.validatus.com/en/docs/from-isolated-automation-to-reliable-processes **Language:** en **Published:** 2026-10-13 **Updated:** 2026-10-13 **Category:** Process Automation **Tags:** Workflow Automation, Automation Governance, IT Operations *Why a workflow is only as dependable as its ability to handle a change of plans.* A new employee is due to join the company in three weeks. HR records the start date. Several automated routines begin working in the background: a user account is created, access permissions are provisioned, a laptop is ordered, and introductory meetings are scheduled. What once required a series of emails and manual requests now happens almost effortlessly. A week later, the employee's start date is postponed by six weeks. HR updates the record. But the automations were designed to respond to the original onboarding event, not to changes that happen afterwards. The account remains enabled. The meetings are still scheduled. The hardware order has already been placed. None of the individual automations necessarily malfunctioned. **The process simply wasn't designed for a situation in which its original assumptions no longer held.** The scenario is hypothetical, but the architectural problem is familiar. ## A trigger is not a process. Much of what we call automation begins with a simple principle: when something happens, perform an action. A new record creates an account. An approval releases an order. A status change sends a notification. These rules are useful. They remove repetitive work and make routine execution more consistent. But a business process is not defined by its first event. It unfolds over time. Conditions change. Decisions are revised. Exceptions arise that were not present when the workflow began. In employee onboarding, creating an account is therefore only one task within a broader process. That process must be able to distinguish between someone who is expected to join, someone whose start date has changed, someone who is authorized to begin work, and someone whose onboarding has been cancelled. **Automation defines what happens when an event occurs. Process architecture must also account for what happens when the meaning of that event changes.** ## Exceptions belong in the design. Nothing technically failed when the start date was postponed. Yet the change raises questions that the original automations cannot answer. Should the account remain disabled until the employee actually starts? Do the permissions require another approval? Can the laptop order proceed? Who makes those decisions? These are not unusual complications to be dealt with after implementation. They are part of what a dependable onboarding process needs to handle. NIST's AC-2 account management control treats user access as an ongoing responsibility. Accounts must be created, modified, reviewed, and disabled in accordance with organizational requirements and changes in personnel status or access needs. The technology to support this kind of lifecycle management already exists. Temporal, for example, allows running workflows to receive external messages and respond to changes in state. Microsoft's durable workflow guidance describes processes that can wait for human approval, react to external events, and handle deadlines. But neither technology can decide what a postponed start date should mean for a particular organization. **Before a workflow can respond intelligently to an exception, the business must define what that exception requires.** ## A dependable process needs a way to change course. Return to our employee. A well-designed workflow would do more than record the revised start date. It would determine which actions already taken need to be reconsidered. Access granted too early might need to be suspended under the organization's access policy. Meetings could be rescheduled. The hardware order might remain valid, require adjustment, or need to be cancelled. Not every action is reversible. A laptop that has already shipped cannot be recalled simply by changing the status of a workflow. That is why reliable processes need more than triggers and successful execution. They need meaningful intermediate states, clear responsibilities, and an established way to handle decisions that cannot safely be automated. Human approval is not always necessary. Many changes can be handled entirely through well-defined rules. What matters is that an unexpected situation does not leave a process silently unfinished. ## Reliability belongs to the whole process. Good process automation therefore begins with a different question. Not simply: Which manual tasks can we eliminate? But: What starts this process? Which conditions must remain true? What can change its course? Who owns unresolved decisions? And how do we establish that the intended business outcome has actually been reached? Answering those questions doesn't necessarily require another workflow platform. Often, a meaningful improvement begins by giving existing automations a clearer understanding of state, change, authority, and exception handling. Google's Site Reliability Engineering guidance makes a similar distinction: automation is powerful, but its value depends on how thoughtfully it is applied. This is what separates a collection of automated tasks from a dependable operating process. **Automation reduces the work when everything goes according to plan. Good architecture ensures the process remains reliable when the plan changes.** --- ## Sources and Further Reading - [NIST — SP 800-53, Account Management (AC-2)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) — Account lifecycle management, access changes, and alignment with personnel processes. - [Temporal — Workflow Message Passing](https://docs.temporal.io/encyclopedia/workflow-message-passing) — Responding to external events and state changes in running workflows. - [Microsoft Learn — Human Interaction Pattern](https://learn.microsoft.com/en-us/azure/durable-task/common/durable-task-human-interaction) — Approvals, external events, durable waiting, and timeouts. - [Google SRE — The Evolution of Automation at Google](https://sre.google/sre-book/automation-at-google/) — The value, limitations, and thoughtful application of automation. *The opening scenario is hypothetical. The technical mechanisms are documented; their application to this onboarding example is an architectural illustration, not a verified customer deployment.*