Copilot Studio Workflows and Flows: Build a Reviewed Process
Copilot Studio offers both classic Power Automate flows and newer agent flows for multi-step automation. Choosing the right model and adding review checkpoints keeps the process reliable and easy to hand off.
Updated 5 min read
Copilot Studio supports two ways to automate work: classic flows triggered from a conversation topic, and agent flows that let an AI reason through a multi-step process on its own. Choosing between them, or combining them, depends on how much the process can be defined in advance and where a human needs to review the result.
A good process does not just run; it records what happened so the next person can verify it. Tools like fenbs keep the decisions behind a workflow, the unresolved follow-up tasks, and the handoff notes outside any one session, so the process survives a change in who is running it.
Classic flows vs agent flows
A classic flow is a Power Automate workflow: a fixed sequence of steps that runs when a topic triggers it. The steps are defined in advance. The flow does exactly what you designed. It is fast, predictable, and easy to audit.
An agent flow is different. The AI is given a goal and a set of available actions, and it decides how to combine them. The assistant can handle inputs it was not explicitly programmed for, but its path is harder to predict and requires more testing. Use a classic flow when the process is well-defined; use an agent flow when the inputs vary enough that a fixed path would break.
Define the process before you build
Before opening the Copilot Studio canvas, write out the process in plain language. What does it start with? What are the possible outcomes? Where does a person need to review the result before work continues? Each decision point is a candidate for a review checkpoint.
Say a three-person operations team wants an assistant that processes a vendor invoice request. The request comes in through a conversation topic, the assistant looks up the vendor in a Dataverse table and checks an approval threshold, and a human approves or rejects above a set amount. That process is well-defined and sequential, so a classic flow is the right model.
Build the classic flow first, then add an agent
Even if you plan to use an agent flow eventually, build the classic version first. A working classic flow confirms that the data connections work, the approvals fire correctly, and the conversation topic hands off cleanly. Once that is stable, you can introduce agent reasoning for the parts of the process where flexibility is genuinely needed.
Agent flows are available as a separate canvas within Copilot Studio. They use a goal-and-tools model: you describe what the agent should accomplish and give it connectors or flows it can call. Keep the first agent flow simple; one goal, two or three tools, and a clear stop condition.
Add review checkpoints at the right moments
A review checkpoint is a pause where a person confirms before the process continues. Common places to add one: when data will be written to a system of record, when an email or notification will go to a customer, or when the value of an approved item exceeds a threshold.
In a classic flow, use an approval action from Power Automate's built-in approval connector. In an agent flow, you can add an explicit confirmation step that asks the user to approve the plan before executing it. Either way, log the approval and its timestamp so there is a record if something is questioned later.
Keep the workflow brief and open follow-ups in fenbs
Add the workflow's purpose, its approval thresholds, and any outstanding decisions as tasks in fenbs. When the process produces a result that needs follow-up, save it as a task with a note on what is waiting. The next person who picks it up reads Where we left off and knows exactly where to start.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Test the whole process, not just each step
Run the flow end to end with realistic data before publishing. A flow that works at each step individually can still fail when the outputs of one step do not match what the next step expects. Check that the approval notification reaches the right person, that the written record lands in the right place, and that the conversation topic reports the outcome clearly to the user.
Test failure paths too. What happens if the vendor is not in the table? What if the approver does not respond within the approval window? A process that handles only the happy path will break on the first unusual input.
How to do this with fenbs
Use fenbs to hold the work brief, the key decisions, and the unresolved issues that arise during building and testing.
- Create a free account and add a project for the workflow or the assistant it belongs to.
- Add a task describing the process: what it does, what data it reads and writes, and where the review checkpoints are.
- Record each approval threshold as a Decision in fenbs with the approver's name and the reasoning, so the number can be found and changed without rebuilding the flow.
- When testing reveals an edge case that needs human review before the process can handle it, add it as a task. Assign it before moving on.
- Before handing the workflow to a new owner, save progress: what the process does, what still needs testing, and what the known limitations are.
fenbs does not monitor your flows or alert you when they fail. Use Power Automate's run history and alerting for that. fenbs keeps the decisions and the follow-up work in one record outside the tool.