How to choose your first workflow to automate

The loudest complaint in a team is not always the best first automation project. A frustrating task might happen rarely, depend on several unrecorded judgments or change every time someone does it. A quieter task may repeat every day with the same inputs and a clear owner. Before choosing a tool, compare the work itself.

A useful first project is small enough to observe from beginning to end. You should be able to identify what starts it, explain the ordinary path and describe what happens when information is missing. You should also know who can stop it. The worksheet below is a planning aid you can adapt to your team, not a validated scoring model or a promise of savings.

Start with three actual candidates

Ask the people doing the work to name three recurring processes. Keep each candidate bounded. “Automate operations” is too broad; “prepare an internal review item when a complete request arrives” is a process someone can inspect. Write down where the information comes from, what result is expected and which person currently takes responsibility for it.

Use recent examples rather than an idealized procedure. A team may describe a process as consistent while quietly fixing a different missing field every day. Look at a small permitted sample, with personal information removed when it is not needed. Record the variation you find. The point is to understand the work before deciding whether an automated action can reliably follow it.

Compare five practical characteristics

For each candidate, consider frequency, rule stability, exception clarity, ownership and reversibility. Use plain labels such as favorable, uncertain and unfavorable. A numerical score can make an early estimate look more precise than it is. Add one sentence of evidence beside each label so another person can challenge it without debating an unexplained total.

Frequency asks how often the process actually occurs. Rule stability asks whether the same input should produce the same next step. Exception clarity asks whether an unusual case can be recognized and routed deliberately. Ownership asks who handles an unfinished item. Reversibility asks how you would recover if the wrong action occurred. A strong first candidate should not rely on an unknown answer to one of those questions.

Work through a small example

Imagine a fictional service team considering three projects: preparing its weekly internal status digest, assigning requests to a review queue and automatically sending final estimates to customers. The digest has stable source fields but inconsistent project updates. Queue assignment has a short category list and a named dispatcher. Estimates require judgments about scope and commercial terms that are not consistently recorded.

The team might choose queue assignment first. It can start in a draft state, leave uncertain categories for the dispatcher and compare proposed assignments with the existing process. The digest remains a possible later project after improving its inputs. The estimates need a more careful design with explicit approval. This choice follows the observed work, rather than assuming that the most visible customer-facing task will be the best demonstration.

Write the decision down with its conditions. For example: “Trial category-based routing for internal review; the dispatcher remains responsible for ambiguous requests; no customer messages are sent.” That sentence makes the boundary testable. If the project later grows to include scheduling or external communication, the team can see that it is making a new decision.

Identify the real starting event

A workflow needs a starting point that matches the process. A new record, a scheduled time and a person pressing a button are different events. Microsoft's Power Automate trigger guide describes these categories. Use them as questions for the process owner before configuring a tool: should every new request start the flow, or should someone confirm that a batch is ready?

Check whether the starting event means what you think it means. A new row may be saved before all its fields are complete. An edited record may be changed several times. A scheduled run may overlap a previous run that has not finished. Ask the implementer to verify the chosen integration's behavior and show how the process handles those situations.

Inspect inputs before promising outputs

List the minimum information needed to make the next decision. For request routing, that might be a category, a location and a contact method. Distinguish required information from information that is merely helpful. A process that accepts an empty required field and guesses its meaning can create work that looks complete while still needing correction.

Decide what happens to incomplete input. A draft queue, a clarification request or a visible stop can all be reasonable choices depending on the work. Give the stopped item an owner and a reason. Avoid treating “someone will notice” as a process step. If nobody checks the queue, the exception route exists only on the diagram.

Keep the first action reversible

A draft record is often easier to inspect and correct than an external message. For a first trial, consider preparing an action for a person to confirm. This lets the team learn from real variation while retaining a clear decision point. It also makes it easier to compare the proposed behavior with the process that people already understand.

Where approval is appropriate, it should be explicit. Microsoft's approval workflow example shows a flow waiting for a decision. Your implementation still needs to define who approves, what they are approving and how an unanswered or rejected item is handled. Adding an approval button alone does not establish those responsibilities.

Choose observations before the trial

Decide what you want to learn. Useful observations include how often input is incomplete, which categories need review, how many items require correction and whether the responsible person can find unfinished work. Record the ordinary workload too. Without context, a single impressive run says little about how the process behaves across a normal week.

Time savings can be considered, but count the new work as well as the old work removed. Someone may now check a queue, maintain a connection or investigate failures. Use actual observations from a defined period if you later make a claim about improvement. Do not turn an early estimate into a promised result for a customer or the team.

Test deliberately awkward cases

Prepare a few fictional examples: one complete request, one missing category, one repeated submission and one request that changes after it has entered review. Ask the implementer to show the result of each. Add an unavailable destination so the team can see how a failure is reported. These cases help reveal whether the process has an understandable recovery path.

A repeated input deserves particular attention when an action creates something. Ask whether another run would create another work item or update the existing one. The answer depends on the implementation and the service involved. The process owner does not need to know every technical mechanism, but should be able to explain the expected outcome and recognize a deviation.

Set a review date and a stopping rule

Give the trial an owner and a specific review point. State what would cause an immediate pause, such as an incorrect external action or a queue that nobody can reconcile. A pause should preserve enough information to understand what happened. Avoid deleting evidence in an attempt to make the system look clean again.

At the review, compare the observations with the original boundary. Keep the workflow small if it still needs attention. Expand it only when the ordinary cases, exceptions and recovery responsibilities are understood. The next step is simple: take three real candidates, write one evidence sentence for each of the five characteristics, and choose the smallest useful process whose unanswered questions can be resolved before the trial.