Halilcan Soran

Tag: Power Automate

  • RPA Is Not the Right Tool for Every Repetitive Task

    RPA Is Not the Right Tool for Every Repetitive Task

    Robot arm reaching for a keyboard representing when RPA is the wrong solution for automation

    The pitch for RPA is always the same: if a human can do it on a screen, a bot can do it instead. That is technically true. It is also one of the most misleading framings in enterprise automation, because it skips the question that actually matters. Just because RPA can do something does not mean RPA should do it. Picking the wrong solution for repetitive task automation is how teams end up six months later maintaining a bot that breaks every time someone resizes a window.

    I have run into this repeatedly. A team identifies a manual, high-volume task, someone says “let’s automate it with RPA,” and the project moves forward before anyone asks whether the underlying system has an API, a database, or a native integration point that would make the whole thing unnecessary. The bot gets built. It works in UAT. It fails in production three weeks later because the source application pushed an update that shifted a button two pixels to the left.

    When RPA Is the Wrong Solution From the Start

    RPA exists to solve a specific problem: you need to automate interactions with a system that offers no other integration path. Legacy applications with no API. Green screen mainframes. Vendor portals that will never expose a connector. When you are genuinely stuck at the UI layer, RPA is the right call and often the only call.

    The problem is that most enterprise environments are not purely legacy. They are a mix. And teams apply RPA uniformly across that mix without checking what integration options actually exist. I have seen bots built to extract data from a SharePoint list by navigating the browser UI, click by click, when a Power Automate flow with the SharePoint connector would have done the same thing in a fraction of the time with none of the fragility. That is not an edge case. That is a recurring pattern.

    If the system you are automating has an API, use it. If it has a native connector in Power Automate, use that. If it can trigger on a database event, trigger on the event. RPA should sit at the end of that decision chain, not the beginning. Reaching for it first because the task looks manual is where the wrong solution gets chosen.

    The Fragility Cost Is Not Theoretical

    UI-based automation is inherently fragile. That fragility has a real maintenance cost that rarely gets priced into the original build decision. Every application update is a potential break. Every UI refresh, every layout change, every new mandatory field added by the vendor is an incident waiting to happen. The bot does not adapt. It fails, usually silently, and keeps “running” in a state that looks like success until someone notices the output queue has been empty for three days.

    I have written before about how Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat, and RPA compounds this problem. A Power Automate flow will at least throw an error you can catch and alert on. An RPA bot that loses its UI anchor can spin through retries, log nothing meaningful, and give every appearance of normal operation while doing nothing at all. The silent failure mode in RPA is worse than most other automation approaches because the bot looks busy.

    The maintenance burden is also not evenly distributed. It tends to land on whoever built the bot, which in most enterprises is a small team. When three bots break in the same week because the same vendor pushed an update, that team is doing triage instead of building anything new. You do not feel that cost during the build. You feel it six months later.

    Process Quality Matters Here Too

    Even when RPA is the correct tool choice, the process underneath still has to be solid. I covered this properly in Automating a Bad Process Just Makes It Fail Faster, but it is worth saying directly in the RPA context: a bot has no instinct. A human doing a repetitive UI task will notice when something looks wrong and stop. The bot will not. It will execute the wrong steps with full confidence until it either crashes or produces consistently incorrect output.

    If the manual process has exceptions, workarounds, and undocumented judgment calls baked in, those do not disappear when you automate it with RPA. They become bot failures with no one to catch them.

    The Decision Should Take Five Minutes

    Before any RPA build starts, the question has to be asked directly: does this system expose any programmatic integration point? API, connector, database access, file-based trigger, anything. Power Automate alone covers hundreds of connectors that eliminate the need for UI automation entirely. If any of those paths exist, take them. They are faster to build, easier to maintain, and more reliable under load.

    RPA earns its place when none of those paths exist. When you are genuinely locked to the UI layer and there is no other way in. That is a real scenario and it happens often enough in large enterprises that RPA is a legitimate part of the toolkit. But it is a last resort, not a default.

    The teams I talk to that are happiest with their RPA implementations are the ones that use it precisely. One system, no API, high volume, stable UI. That is the sweet spot. The ones that are drowning in maintenance are the ones that used it everywhere because it felt like the fastest path to a demo.

    Fast to demo is not the same as right to build. I learned that the hard way. You can connect with me on LinkedIn if you want to talk through where RPA actually fits in your stack.

    Frequently Asked Questions

    When is RPA the wrong solution for automating a repetitive task?

    RPA is the wrong solution when the system you want to automate already has an API, a native connector, or a database trigger available. In those cases, tools like Power Automate or direct integrations are faster to build, more reliable, and far easier to maintain than a UI-based bot.

    Why does RPA break so often in production?

    RPA bots interact with applications at the UI layer, which means any visual change to the application can cause them to fail. A button that moves, a new mandatory field, or a layout refresh pushed by a vendor update can all break a bot that worked perfectly during testing.

    When should I use RPA instead of an API or native connector?

    RPA makes sense when you are working with a system that has no API, no integration connectors, and no way to trigger automation through a database event. Legacy applications and vendor portals with no developer access are the clearest use cases where RPA is genuinely the right call.

    How do I decide whether to use RPA or a different automation tool?

    Start by checking whether the target system exposes an API, supports a native connector, or can trigger on a data event. Only if none of those options exist should RPA be considered. Treating it as a last resort rather than a first choice avoids most of the fragility and maintenance problems teams run into.

  • Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat

    Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat

    People keep asking in the community what makes an agentic workflow actually useful. The honest answer is that most things being called agentic workflows right now are not. They are linear automations with a language model bolted on for the response step. That distinction matters more than most teams realise when they start building.

    What a Useful Agentic Workflow Actually Does

    A useful agentic workflow does something a standard Power Automate flow cannot: it makes decisions mid-execution based on context it discovered during the run, not based on conditions you hard-coded before it started.

    That sounds obvious. It is not, in practice.

    A flow that checks a field value and routes left or right is not an agent. An agent is something that can retrieve information it did not start with, reason about what that information means for the current task, and take a different action than you would have anticipated when you designed it. The key word is discovered. The agent had to go and find out something, then act on it.

    If you can fully diagram the execution path before the workflow runs, it is probably not agentic. It is a well-structured flow. There is nothing wrong with a well-structured flow. But you should not be paying the overhead of agent infrastructure to build one.

    Where Teams Go Wrong Building Agentic Workflows

    The most common mistake I see is treating the language model as the agent. The LLM is not the agent. The LLM is the reasoning layer. The agent is the system that decides when to call what tool, handles what comes back, and determines whether the result is good enough to proceed or whether it needs to try something else.

    When that orchestration layer is weak or missing, you get a workflow that calls one tool, takes the output at face value, and moves on. That is not reasoning under uncertainty. That is a glorified lookup with a friendly response message.

    I wrote about silent action failures in the context of Copilot Studio earlier (the production testing post covers this in detail). The same failure mode appears in agentic workflows, but it is worse because the agent has more steps where it can silently accept a bad result and keep going. A flow fails at a specific action. An agent can propagate a bad intermediate result through three more steps before anything looks wrong.

    The Two Things That Make or Break an Agentic Workflow

    Based on what I have built internally and what I hear from people at other organisations, it comes down to two things.

    First: tool design. The actions available to your agent need to return enough context for the agent to evaluate them, not just a success or failure signal. If your Power Automate flow returns {"status": "done"}, the agent has no way to assess whether done means what the user needed. It will treat it as success. Your tools need to return structured, interpretable output. This is not a language model problem. It is an API design problem.

    Second: failure handling that is explicit, not optimistic. A useful agent knows when it is stuck and does something about it. That might mean escalating to a human, asking the user for clarification, or stopping cleanly with an honest message. What it does not do is generate a confident-sounding response for a task that did not complete. That is the failure mode that destroys trust in agents faster than anything else, because the user finds out later, not immediately.

    I covered how this plays out in Copilot Studio specifically in the post on when Copilot Studio is the wrong choice. But the principle applies regardless of the tooling. An agent that cannot fail gracefully is not useful in production. It is a liability.

    What Agentic Workflows Are Actually Good For

    The use cases where agentic workflows justify their complexity share a few characteristics. The task has multiple possible paths and you cannot enumerate them all upfront. The inputs are unstructured or variable enough that rule-based routing breaks down. The system needs to recover from partial failures without a human in the loop for every edge case.

    Document processing that involves extracting, validating, cross-referencing, and then acting on extracted data is a reasonable fit. Multi-step research tasks where what you search for next depends on what you found are a reasonable fit. Anything where the decision logic changes frequently and hard-coding it into a flow becomes a maintenance problem is worth evaluating. Before committing to that architecture, though, it is worth asking whether the underlying process is actually sound — automating a bad process just makes it fail faster, and agentic workflows are no exception.

    A status check is not a fit. A single-action task triggered by a button is not a fit. Anything you can build cleanly as a Power Automate flow with proper error handling is probably not worth the overhead of an agentic architecture. The orchestration cost is real and the debugging surface is larger.

    The Test I Use

    Before committing to an agentic workflow architecture, I ask one question: does this task require the system to discover something during execution that changes what it does next, and would that discovery be different for different runs? As Halilcan Soran on LinkedIn, I have found this single question filters out more false positives than any other test I use.

    If yes, agents are worth the investment. If no, you are adding complexity to solve a problem that a well-built flow could handle, and you will spend more time debugging Claude or other AI agent behaviour than you saved on logic design.

    The technology is not the constraint. Knowing what you are actually building is.

    Frequently Asked Questions

    What

  • Automating a Bad Process Just Makes It Fail Faster

    Automating a Bad Process Just Makes It Fail Faster

    I came across a post from Zapier Blog about process improvement recently, and it made a familiar point: most broken work isn’t actually broken work, it’s a broken process behind it. Messy handoffs, unclear ownership, approvals that live in one person’s head. Good framing. But it treats process improvement before automation as something you do once, upfront, like a checklist item you can tick and move past. In enterprise Power Platform work, that assumption is where things go wrong.

    What Building Automations Teaches You About How Work Actually Flows

    When you sit down to build a flow, you have to make the process machine-readable. That means every branch needs a condition. Every input needs a defined type. Every approval needs an owner. Every exception needs a path.

    Most processes handed over for automation have none of that. What they have instead is a document someone wrote two years ago, a few spreadsheets nobody fully trusts, and a senior colleague who holds the real logic in their head and has been doing it long enough that they don’t notice the decisions they’re making.

    The automation developer ends up being the first person to actually interrogate the process at that level of detail. Not because they went looking for it, but because the flow won’t build until the ambiguity is resolved. You cannot write a condition on a field that sometimes exists and sometimes doesn’t. You cannot route an approval to a role when the role changes depending on factors nobody documented.

    This is not a Power Platform problem. It surfaces in every serious automation project I’ve heard about across different organisations. The tool just makes the gaps visible faster than any process workshop usually does.

    The Specific Process Failures That Surface When You Try to Automate

    There are a few categories I keep running into.

    Unclear ownership. A task gets triggered, but nobody agreed who acts on it. The automation sends an email. Nobody responds. The flow sits waiting. Eventually it times out. Everyone blames the automation.

    Inconsistent inputs. The data coming in doesn’t conform to any standard. Fields are free text when they should be dropdowns. Dates are formatted three different ways. Required fields are blank because the upstream system never enforced them. Your flow handles the clean case fine and breaks silently on everything else. I wrote about this kind of silent failure in the context of Copilot Studio agents failing in production, but the same thing happens in flows where bad input just passes through without raising an error until something downstream breaks.

    Approval logic nobody can fully articulate. You ask who approves a request above a certain threshold. You get three different answers from three different people. All of them are confident. When you automate the majority answer, you will eventually automate the wrong one for someone’s edge case, and that person will be senior enough that it becomes your problem.

    Exception handling that lives in tribal knowledge. The manual process survives because a human notices something feels off and picks up the phone. The automated process has no equivalent. The exception just propagates.

    Why Fixing the Process First Does Not Mean Waiting to Build

    The standard advice is to fix the process before you automate it. That advice is correct and also almost never followed, because the people who own the process don’t feel urgency until they see the automation breaking. The broken automation is what creates the pressure to fix the underlying problem.

    This doesn’t mean you should automate bad processes and hope for the best. It means process improvement and automation are parallel work, not sequential steps. You build, you find the gap, you surface it to the right person, you agree on a rule, you build that rule into the flow. Then you find the next gap.

    The first build is often a diagnostic as much as a delivery. You are not just producing a flow. You are producing a map of where the process is genuinely undefined. That map is more useful than most process workshops, because it was produced by the requirement to actually execute the logic rather than describe it at a whiteboard.

    The risk is treating that diagnostic build as the final product. It isn’t. The flow that handles the happy path and ignores edge cases is not done. It is a prototype that revealed the real work. Those edge cases are also where Power Automate throttling limits tend to surface, once real volume hits paths that were never properly stress-tested.

    How to Pressure-Test Process Logic Before You Commit It to a Flow

    Before building anything complex, I walk through the process as if I were writing the conditions myself, not interviewing someone about it. Specifically:

    • Ask what happens when a required field is missing. If the answer is “that doesn’t happen,” it will happen.
    • Ask who the fallback approver is when the primary approver is unavailable. If there isn’t one, your flow will block silently until someone notices.
    • Ask what the exception path looks like and who owns it. If the answer is vague, you have found the part of the process that was always handled by instinct rather than logic.
    • Take a real sample of historical cases and walk them through your intended logic manually before writing a single action. The cases that don’t fit cleanly are the ones that will break production.

    This is not a formal methodology. It is just refusing to start building until the people handing over the process can articulate it clearly enough that you could explain it to someone else and they would reach the same conclusions. When they can’t, that gap is not a problem with your discovery process. It is the actual problem you are being asked to solve. As Halilcan Soran on LinkedIn and others working in enterprise automation have found, this kind of rigorous process interrogation is often what separates automations that survive their first month in production from the ones that quietly fail or require constant manual workarounds. If you want to understand how Power Platform automation should work at scale, this pressure-testing phase is non-negotiable.

  • Low-Code Platform Comparisons Miss the Point for Enterprise Power Platform Teams

    Low-Code Platform Comparisons Miss the Point for Enterprise Power Platform Teams

    I came across a post from Zapier Blog ranking the best low-code automation platforms, and it reminded me of a conversation I keep having with stakeholders. Someone reads a roundup, sends it over, and asks why we are not using one of the other tools on the list. The question sounds reasonable. The comparison is not. For teams doing power platform for enterprise automation, these lists are almost always built around the wrong frame entirely.

    Why Platform Comparison Lists Are Built for Buyers Who Do Not Exist in Enterprise

    Roundups like this are useful for one type of reader: someone at a small company, starting from scratch, with no existing infrastructure, who needs to pick a tool this week. That reader exists. Most people building automation inside a large organisation are not that reader.

    Enterprise teams are not choosing between platforms in a vacuum. They are operating inside a tenant. They have an existing Microsoft 365 agreement. They have an IT security function that has already decided what can touch production data. They have a DLP policy, or they are about to have one. The question is never which platform wins a feature comparison. The question is what is already inside the perimeter and how far can it go.

    When the starting point is a Microsoft 365 E3 or E5 agreement, Power Platform is not an option on a menu. It is largely already there. The conversation is about how deeply to use it, not whether to adopt it at all.

    What These Roundups Get Wrong About How Power Platform Actually Works at Scale

    The comparisons that show up in these lists treat features as equivalent when they are not. They will note that Power Automate supports HTTP connectors, and so does Zapier, so check. They will note that both have flow triggers and conditional logic. Check and check.

    What they do not cover is how governance works when you have hundreds of flows built by dozens of makers across multiple environments. Power Platform has environment-level DLP policies that enforce which connectors can interact with which data classifications. You can block a connector tenant-wide from the admin centre. You can require solution-aware flows before anything goes near a production environment. None of that is a feature you evaluate in a roundup. It is architecture you depend on when something goes wrong at 2am and you need to know exactly what touched what.

    Connector-level governance also ties directly into Entra ID. Service principal authentication, conditional access policies, managed identities for flows that call Azure resources. These are not nice-to-haves. They are what your security team will ask about before any automation touches HR data or finance systems. A platform comparison that does not address this is not comparing the same thing your enterprise is actually buying.

    The Governance and Tenant Boundary Argument Nobody in These Lists Makes

    The argument that actually matters for enterprise teams is about the boundary. Everything inside your Microsoft tenant shares an identity layer, a licensing model, an audit log, and a set of compliance controls. Power Platform lives inside that boundary by design. When a Power Automate flow calls Dataverse, or a Copilot Studio agent hands off to an AI Builder model, or a Power App writes back to SharePoint, none of that crosses a boundary. It is all inside the same governance envelope.

    When you bring in a third-party automation tool, you immediately introduce a boundary crossing. Data leaves the tenant. Authentication has to be managed separately. Your audit trail splits. Your DLP logic does not follow. That is not an argument against ever using other tools. But it is the argument that platform comparison lists never make, because they are not written for people managing compliance obligations across a 10,000-person organisation.

    I have written before about how throttling in Power Automate has two distinct layers, platform-level and connector-level, and understanding which one you are hitting matters. The same principle applies here. There are two distinct layers to platform selection: what the tool can do, and what the tool is allowed to do inside your security perimeter. Most comparison articles only address the first layer.

    How to Respond When a Stakeholder Sends You One of These Articles

    This happens. Someone senior reads a roundup, sees that another tool scored well on ease of use or pricing, and asks a reasonable question. Here is how I handle it.

    First, do not get defensive about Power Platform. That reads as tribal and closes the conversation. Instead, reframe the question. The roundup is answering “which tool is easiest to try”. The enterprise question is “which tool can we govern, audit, and scale without introducing a new identity boundary or violating our data residency requirements”.

    Second, be specific about what already exists. If you have 200 flows in production, connectors pre-approved by security, an admin centre your IT team actually monitors, and makers who already know the platform, the switching cost is not zero. It is very large. That context belongs in the conversation.

    Third, acknowledge what the other tools do well. Zapier is genuinely easier to set up for a simple two-step integration. Make has a visual canvas that some people find clearer than Power Automate’s. Agreeing on the narrow case where another tool wins builds credibility for the broader argument about why it does not win at enterprise scale. The same logic applies when teams start layering AI into their automations: as I explored in Agentic Workflows Are Not Just Fancy Automation, adding an AI layer does not transform a poorly governed process into a reliable one, regardless of which platform you are on.

    The roundup is not wrong. It is just answering a different question. Once you say that clearly, the conversation usually moves to something more useful than defending a platform choice that was effectively made the day the Microsoft agreement was signed.

    Frequently Asked Questions

    Why should enterprises use Power Platform for enterprise automation instead of other low-code tools?

    For most large organisations, Power Platform is already included in their Microsoft 365 agreement, so the decision is less about choosing a tool and more about how deeply to use one that is already available. It also integrates directly with existing Microsoft security infrastructure, including Entra ID, conditional access policies, and tenant-level governance controls that other platforms simply cannot replicate in that environment.

    How do I govern Power Automate flows across a large organisation?

    Power Platform allows admins to apply environment-level DLP policies that control which connectors can access which types of data, and connectors can be blocked tenant-wide from the admin centre. Requiring solution-aware flows before anything reaches a production environment adds another layer of control, giving teams a clear audit trail when something needs investigating.

    What is a DLP policy in Power Platform and why does it matter for enterprise teams?

    A DLP (Data Loss Prevention) policy in Power Platform defines which connectors can interact with business or sensitive data within a given environment. For enterprise teams handling HR or finance data, these policies are a security requirement rather than an optional feature, and they are enforced at the tenant level rather than left to individual flow builders.

    When should I question a low-code platform comparison for enterprise use?

    Most platform comparison lists are designed for small teams starting from scratch with no existing infrastructure, which is a very different situation from a large organisation with an established Microsoft 365 tenancy and security requirements already in place. If a comparison does not address governance at scale, service principal authentication, or tenant boundary controls, it is not evaluating the same things your enterprise actually needs.

    This post was inspired by The 7 best low-code automation platforms in 2026 via Zapier Blog.

  • Power Automate Throttling Limits Will Break Your Flow in Production

    Power Automate Throttling Limits Will Break Your Flow in Production

    If you have ever had a Power Automate flow run perfectly in testing and then start failing two weeks after go-live, Power Automate throttling limits are a likely culprit. Not a bug in your logic. Not a connector issue. Just the platform telling you that you asked for too much, too fast.

    This post is not about what throttling is in theory. It is about what it looks like when it hits you, and what you can actually do about it.

    What Power Automate Throttling Actually Looks Like

    Throttling in Power Automate surfaces as HTTP 429 errors. You will see them in your flow run history as failed actions, usually on connector calls. SharePoint, Dataverse, and HTTP actions are the most common places I see them show up.

    The problem is that most people do not notice at first. The flow has retry logic built in by default, so it quietly retries and sometimes succeeds. Then load increases. Retries stack up. Runs queue behind each other. Eventually things time out or fail hard, and by then you have a real incident on your hands.

    I ran into this building a document processing flow internally. Under testing with twenty files it was fine. Under real load with several hundred files triggered in a short window, the SharePoint connector started returning 429s, retries piled up, and runs that should take seconds were taking minutes or failing entirely.

    Understanding the Two Layers of Throttling

    There are two distinct layers and conflating them leads to bad fixes.

    The first is platform-level throttling. Power Automate itself limits how many actions a flow can execute per minute and per day depending on your licence tier. Performance tier and Attended RPA add-ons give you higher limits. If you are running high-volume flows on a standard per-user licence, you will hit these limits faster than you expect.

    The second is connector-level throttling. This is imposed by the service on the other end, not by Power Automate. SharePoint has API call limits per user per minute. Dataverse has its own service protection limits. An external API you are calling over HTTP has whatever limits its vendor decided on. Power Automate has no control over these, and the retry behaviour it adds does not always help if you are genuinely over the limit.

    Most tutorials only mention one of these. Then your flow breaks in prod and you spend an afternoon figuring out which layer you actually hit.

    How to Handle Power Automate Throttling Limits

    There is no single fix. The right approach depends on which layer is throttling you and why.

    Slow down intentional bulk operations. If your flow is processing items in a loop, add a Delay action inside the loop. Even a one or two second delay dramatically reduces API pressure. It feels wrong to add artificial waits, but it is far better than random failures.

    Reduce concurrency. By default, Apply to Each runs with a concurrency of 20 or 50 depending on settings. Dropping this to 1 or 5 is often enough to stop triggering connector-level throttling. Yes, your flow will run slower. That is usually acceptable. Failed runs are not.

    Batch instead of looping. SharePoint and Dataverse both support batch operations. If you are creating or updating records one at a time in a loop, look at whether you can batch those calls. Fewer requests means less throttling exposure.

    Check your licence tier against your actual volume. This one people skip. If you are running flows that process thousands of actions per day, look at your licence entitlements honestly. The Power Automate Process licence exists for high-volume scenarios. Using a per-user licence for something that genuinely needs a process licence is not a workaround, it is a problem waiting to happen.

    Do not rely on default retry logic as a strategy. The built-in retry handles transient blips. It is not designed to absorb sustained throttling. If your flow needs retries to survive normal operating conditions, that is a signal to fix the root cause, not tune the retry settings.

    The Monitoring Gap

    Most teams I talk to have no visibility into throttling until something breaks. Flow run history shows failures, but it does not surface throttling patterns clearly. Setting up alerts on failed runs is table stakes. What is less common is tracking run duration over time. A flow that starts taking twice as long to complete is often being quietly throttled before it starts failing outright.

    Azure Monitor and the Power Platform admin centre both give you data here. Use them before users start sending messages asking why the automation is slow.

    The Bottom Line

    Power Automate throttling limits are not a corner case. They are something you will hit if your flows handle real enterprise volume. The fix is almost never a single setting. It is a combination of slowing down bulk operations, reducing concurrency, batching where possible, and being honest about whether your licence matches your workload. If you are also thinking about how automation fits into larger orchestration patterns, agentic workflows are not just fancy automation and require a fundamentally different design approach from the start. As Halilcan Soran on LinkedIn, I have seen firsthand how critical this planning is in enterprise deployments.

    Test under realistic load before go-live. Not twenty items. The actual volume you expect in week three after rollout.

    Frequently Asked Questions

    What are Power Automate throttling limits and why do they cause flows to fail?

    Power Automate throttling limits are restrictions on how many actions or API calls your flow can make within a given time window. There are two layers: platform-level limits set by Microsoft based on your licence tier, and connector-level limits imposed by external services.

  • Agentic Workflows Are Not Just Fancy Automation

    Agentic Workflows Are Not Just Fancy Automation

    The mistake I keep seeing

    A client comes in. They’ve heard about AI agents. They want to ‘add AI’ to their approval workflow. So they take the existing 10-step Power Automate flow, stick a Copilot Studio agent somewhere in the middle, and call it an agentic workflow.

    It isn’t. It’s just the old process with a chatbot attached.

    This is the most common mistake I see right now, and it’s costing teams time and credibility. The agent becomes a fancy input form. The process stays broken. And when it fails — and it does — everyone blames the AI.

    What actually makes a workflow agentic

    An agentic workflow is not about adding a language model to a flow. It’s about giving the system the ability to reason about what to do next, not just execute a predefined sequence.

    The difference matters. In a traditional flow, you define every branch. Every condition. Every outcome. The machine follows instructions. In an agentic workflow, the agent interprets a goal, decides which tools or actions to use, and adjusts based on what it gets back.

    That requires a fundamentally different design approach. You’re not mapping steps — you’re defining boundaries, tools, and acceptable outcomes.

    Three things that have to change in your process design

    • Stop thinking in sequences. Agentic workflows are goal-driven, not step-driven. Define what done looks like, not every micro-step to get there. If your flow diagram looks like a subway map, you’re still in traditional automation mode.
    • Give the agent real tools, not just data. An agent that can only read a SharePoint list and send an email is not doing much reasoning. It needs to call APIs, query systems, write back to records, trigger sub-flows. Tool design is where most implementations fall apart — people give agents access to everything or nothing. Neither works.
    • Build in failure handling at the goal level. Traditional flows handle errors at the step level — if this action fails, go here. Agentic workflows need you to think about what happens when the agent reaches a dead end, produces a low-confidence result, or loops without resolution. I’ve seen agents spin for 40 iterations on a task that should have escalated to a human after three.

    Where this actually works in business processes

    Not everywhere. I want to be direct about that.

    Agentic design makes sense when the process has variability that you cannot fully predict upfront. Invoice exceptions. Complex customer complaints. Multi-system data reconciliation where the right answer depends on context you only know at runtime.

    It does not make sense for processes that are well-defined and stable. If your purchase order approval follows the same 6 steps every time, a standard Power Automate flow is the right tool. Don’t add an agent to it just because you can.

    The teams that get the most out of agentic workflows are the ones who identify a process where exceptions are eating their staff’s time, then let the agent handle the exceptions rather than replacing the whole flow.

    The orchestration layer nobody talks about

    When you start running multiple agents — one for document processing, one for customer communication, one for system updates — you need something coordinating them. This is where I see projects go sideways fast.

    In Copilot Studio and Power Platform, you can build orchestrating agents that hand off to specialist agents. But the handoff logic, context passing, and failure recovery across agents is not something the platform handles automatically. You have to design it. Most tutorials skip this. Then your multi-agent setup breaks in production because Agent B has no idea what Agent A already tried.

    Document your agent boundaries explicitly. What does each agent know? What can it do? What should it never do? Treat it like designing a team of junior staff who are fast and tireless but have no common sense unless you’ve given them the right context.

    Start smaller than you think you should

    Pick one process. One that has clear exceptions, high manual effort, and a measurable outcome. Build the agent, give it two or three tools, test it against real historical cases before you deploy it anywhere near live data.

    The teams that succeed with agentic workflows in 2026 are not the ones with the biggest ambitions. They’re the ones who are rigorous about scope, honest about where the agent is making decisions versus guessing, and fast to pull the agent out of the loop when something looks wrong.

    Agentic is a design philosophy. Apply it where it earns its complexity.