Halilcan Soran

Tag: RPA

  • Attended vs Unattended RPA for Power Automate Desktop Flows

    Attended vs Unattended RPA for Power Automate Desktop Flows

    Two computer setups side by side illustrating attended vs unattended RPA in Power Automate desktop flows

    You built the desktop flow. It works. Now comes the question that actually decides the economics of the whole project: does it run on a person’s machine while they watch, or on a dedicated machine at 3 AM with nobody around? That is the attended vs unattended RPA decision, and I keep seeing teams get it wrong in both directions. Some pay for unattended bots to run flows that need a human answer halfway through. Others burn an employee’s afternoon babysitting a flow that should have been scheduled on a VM.

    I have built both kinds. Here is how I compare them now, dimension by dimension.

    The Attended vs Unattended Cost Gap

    Attended RPA is included in the Power Automate Premium per-user licence, which sits around $15 per user per month. If a person is signed in and triggers the flow on their own machine, that licence covers it.

    Unattended is a different animal. The unattended process licence runs around $150 per bot per month, and if you want Microsoft to host the machine for you, the hosted process option lands around $215 per month. Want two flows running concurrently on the same machine? That is another unattended licence. This is the ten-times gap, and it is where How to Run a Power Platform Licensing Audit Before You Ship earns its keep. I have watched estimates double after someone finally read the concurrency rules.

    Machine and Session Requirements

    Attended flows need an active, unlocked Windows session. The user is signed in, the screen is visible, and the flow drives the UI in front of them. Lock the screen mid-run and the flow dies. That is not a bug. It is the definition of attended.

    Unattended flows create their own session on a machine where nobody is signed in. That means the machine must allow it: no other active session on that account, credentials stored in the connection, and on standard Windows 10 or 11 you get exactly one unattended run at a time per machine. Multiple parallel sessions need Windows Server or multiple machines in a machine group. The Microsoft Learn requirements for unattended runs are strict, and every requirement you skip becomes a 4 AM failure.

    Failure Modes

    Attended flows fail loudly and recover cheaply. The user is right there. A selector breaks, a popup appears, the flow stops, the human clicks past it and reruns. Annoying, but the blast radius is one person’s afternoon.

    Unattended flows fail silently and recover expensively. Nobody sees the unexpected dialog box. The run sits there until timeout, the queue backs up, and you find out from the downstream team the next morning. Everything covered in Selectors vs Image Recognition for Power Automate Desktop Flows matters three times more unattended, because there is no human to absorb the surprise. If you go unattended, you also need error handling, screenshots on failure, and alerting. Budget that build time. It is not optional.

    Human in the Loop

    Some processes genuinely need a person mid-flow. A judgment call, an approval, a value read off a paper document. Attended handles this naturally with input dialogs. Unattended cannot do it at all, and I have seen teams contort a process into ugly two-phase flows just to force it unattended. If a human decision sits in the middle of your process, that is your answer. Do not fight it.

    Throughput Ceiling

    This is where unattended wins without argument. An attended flow runs when a human is available, which means business hours, one run at a time, competing with the person’s actual job. An unattended machine group with three VMs runs around the clock and processes a queue in parallel. If your volume is hundreds of transactions a day, attended is not a real option no matter how cheap the licence looks. Concurrency also introduces its own gotchas inside the flows themselves — why variables break when you turn on concurrency in Power Automate is worth reading before you scale a machine group.

    At a Glance

    Dimension Attended Unattended
    Licence cost ~$15/user/month (Premium) ~$150/bot/month, ~$215 hosted
    Session User signed in, unlocked Bot creates its own session
    Failure recovery Human fixes it live Needs alerting and retry logic
    Mid-flow human input Native Not possible
    Throughput Business hours, serial 24/7, parallel with machine groups

    Choose Attended If, Choose Unattended If

    Choose attended if the process needs human judgment mid-run, if volume is low enough that a person triggering it is not a bottleneck, or if you are still stabilising the flow and want a human catching the surprises. It is also the honest choice for a pilot. Prove the flow works attended before paying unattended prices.

    Choose unattended if volume demands overnight or parallel runs, if the process is fully deterministic with no human decision anywhere, and if you have already invested in error handling and monitoring. And before either: check whether the target system has an API. As I have argued before, a lot of desktop flows should not exist at all. The best RPA licence is the one you never had to buy. More of my reasoning on these trade-offs is on my LinkedIn.

    Frequently Asked Questions

    What is the difference between attended vs unattended RPA in Power Automate Desktop?

    Attended RPA runs on a user’s machine while they are actively signed in, with the flow triggered by the person in front of it. Unattended RPA runs on a dedicated machine with no one present, typically on a schedule, creating its own session automatically. The key distinction is whether a human needs to be available during the run.

    How much does unattended RPA cost compared to attended in Power Automate?

    Attended automation is covered under the Power Automate Premium per-user licence at around $15 per user per month. Unattended requires a separate process licence at roughly $150 per bot per month, rising to around $215 if you use Microsoft-hosted machines. Running flows concurrently requires additional licences, which can cause costs to climb quickly.

    When should I use attended RPA instead of unattended for desktop flows?

    Use attended RPA when the process requires a human decision or input at some point during the run, or when the volume does not justify the higher licence cost. Unattended is better suited for high-volume, fully automated processes that can run overnight or in bulk without any human involvement.

    Why does my unattended desktop flow fail when no one is watching?

    Unattended flows can fail silently because there is no user present to handle unexpected popups, broken selectors, or login prompts. Unlike attended flows where a person can intervene immediately, unattended runs may sit idle until they time out, causing queues to back up before anyone notices the issue.

  • Selectors vs Image Recognition for Power Automate Desktop Flows

    Selectors vs Image Recognition for Power Automate Desktop Flows

    Comparison of Power Automate Desktop selectors and image recognition for UI automation reliability

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published August 2, 2026

    Every desktop flow forces the same decision at some point: do you target the application through Power Automate Desktop selectors, or do you fall back to image recognition and click on pixels? I have built flows both ways, and I have babysat flows built both ways. The short answer is that selectors break less often and are cheaper to fix. But the honest answer needs numbers, because there are situations where image recognition is genuinely the only option, and pretending otherwise sets teams up for pain.

    One caveat before the comparison. If the target system has an API or a documented connector, neither of these is the right answer. I wrote about that in Stop Reaching for Desktop Flows. This post assumes you have already lost that argument and the UI is all you have.

    What Breaks Power Automate Desktop Selectors

    Selectors read the application’s accessibility tree. They break when the tree changes: a developer renames a control, an update reshuffles the window hierarchy, or the selector was recorded with a fragile ordinal like Button[3] instead of a stable attribute like AutomationId. The failure is loud and specific. You get an error naming the exact UI element that could not be found, and the flow stops at that step.

    Image recognition breaks when pixels change. A theme update, a new font, Windows display scaling moving from 100% to 125%, a notification toast overlapping the target, or an unattended machine resolving at 1024×768 instead of the 1920×1080 you recorded at. None of these are code changes. Most of them are things IT does without telling you. The failure is often not even a failure: the match lands on the wrong lookalike button and the flow keeps running with wrong data.

    Maintenance Cost

    When a selector breaks, I open the UI element repository, repair one attribute, and I am done in ten minutes. The fix is surgical because the error tells me exactly which element died. Better yet, editing the custom selector to use wildcards on volatile attributes (window titles that include document names, for example) prevents whole categories of future breaks.

    When an image match breaks, I have to reproduce the exact visual state of the machine to re-capture the image. If the flow runs unattended, that means connecting to the runner, matching its resolution and scaling, and re-recording. I have seen a single Windows font scaling change take out six image-based steps across three flows in one morning. Each one needed a new capture. There is no surgical fix for pixels.

    Environment Sensitivity

    Selectors are largely immune to resolution, scaling, and theming. The accessibility tree does not care whether the window is maximized or what DPI the session runs at. This matters enormously for unattended runs, where the RDP session Power Automate creates may not match your development machine at all.

    Image recognition is hostage to the environment. You can loosen the tolerance parameter (it defaults to 10 in PAD’s image actions) to survive minor rendering differences, but every point of tolerance you add increases the chance of a false positive match. Tight tolerance breaks on scaling changes. Loose tolerance clicks the wrong thing. There is no setting that gives you both.

    Debuggability

    A failed selector produces an error message with the element name and the step. You can read the run history in the Power Automate Desktop portal and know what happened without touching the machine. A failed or mismatched image gives you “image not found” at best and silent wrong-clicks at worst. Diagnosing it means screenshots, session recordings, and guesswork. The same principle that makes AI agents fail in production when they worked fine in testing applies here: silent failures and poor observability compound until something important breaks without warning.

    Dimension Selectors Image recognition
    Breaks on UI tree changes Any pixel change
    Fix time Minutes, one attribute Re-capture on matching environment
    DPI and resolution Mostly immune Highly sensitive
    Failure mode Loud, named element Silent wrong-clicks possible

    Where Image Recognition Actually Wins

    Citrix and RDP sessions where the remote application streams as a bitmap and exposes no accessibility tree. Legacy Java apps without the access bridge configured. Canvas-rendered UIs that paint everything into a single element. In these cases selectors return nothing and image recognition, ideally combined with OCR to verify state before clicking, is the legitimate tool. In my experience, that covers maybe one flow in ten. The rest use images out of convenience, and convenience at build time is fragility at run time.

    The Decision Rule

    Choose selectors if the accessibility tree exposes the element at all, even if you have to hand-edit the selector with wildcards to make it stable. Choose image recognition only when the tree is genuinely empty, and when you do, pin the runner’s resolution and scaling, verify with OCR before destructive clicks, and document the capture environment. If you are routing outputs from these flows into Power Platform agents, the same measurement discipline covered in How to Measure Useful Work Per Dollar for Your Power Platform AI Agents applies: you need to know whether the automation is actually completing useful work, not just running without errors. Drag and drop fast. Plan even faster.

    Frequently Asked Questions

    When should I use Power Automate Desktop selectors instead of image recognition?

    Power Automate Desktop selectors are the better default choice because they read the application’s accessibility tree rather than pixels, making them resistant to resolution changes, theme updates, and display scaling. Image recognition is only worth considering when a UI element has no accessible properties for a selector to target.

    Why do Power Automate Desktop selectors break after application updates?

    Selectors break when the underlying accessibility tree of the application changes, such as when a developer renames a control or a software update reshuffles the window hierarchy. Using stable attributes like AutomationId instead of positional references like Button[3] reduces how often this happens.

    Why does image recognition in Power Automate Desktop click the wrong element?

    Image recognition matches on pixels, so changes like a new font, a notification covering the target, or a different screen resolution can cause the match to land on the wrong button without throwing an error. This makes failures harder to detect because the flow continues running with incorrect actions.

    How do I reduce maintenance work when desktop flow UI elements keep breaking?

    Switch from image-based clicks to selectors wherever possible, since selector errors identify the exact element that failed and repairs are usually quick attribute fixes. Using wildcards on volatile parts of a selector, such as window titles that include document names, can also prevent entire categories of recurring breaks.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Stop Reaching for Desktop Flows When a Cloud Flow Would Do the Job

    Stop Reaching for Desktop Flows When a Cloud Flow Would Do the Job

    Decision guide for cloud flows vs desktop flows in Power Automate

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published June 29, 2026

    I keep seeing the same pattern on LinkedIn and in community calls. Someone builds a desktop flow to read an Outlook inbox. Someone else builds a desktop flow to write rows into SharePoint. Then they wonder why the bot crashes every time IT pushes a Windows update. The cloud flows vs desktop flows decision is not a style choice. It is an architecture choice, and most teams get it backwards.

    The problem

    People reach for desktop flows because they saw a demo where someone automated a click on a button and it felt powerful. So now every automation idea starts with Power Automate Desktop open and a recorder running. That is how you end up with a UI automation reading an Exchange mailbox that has had a documented Graph API for years.

    Here is the rule I use, and it has not failed me yet.

    If the system has an API or a connector, use a cloud flow. If it does not, use a desktop flow. That is it.

    Everything else is rationalisation. Outlook has a connector. SharePoint has a connector. Dataverse has a connector. SAP has a connector. ServiceNow has a connector. Salesforce has a connector. If you are clicking buttons in any of these with Power Automate Desktop, you are building a fragile silo for a problem that was already solved.

    Cloud flow Desktop flow
    Target has a first-party connector Always. Over 1000 connectors exist. Never. You are rebuilding a solved problem.
    Target has a documented REST API Custom connector or HTTP action. One-time investment. No. UI automation against an API-backed system is selector fragility for nothing.
    Legacy app, Citrix, thick client, no API Not possible. The one real use case. Build it knowing the maintenance cost.
    Typical failure mode API error you can read and handle. Moved window, font scaling change, 3am patch reboot.
    Maintenance Low after setup. Babysitting forever.

    The fix

    Before you open Power Automate Desktop, run through three checks.

    Check 1. Does the target system have a Power Automate connector? Go to the connector reference and search. There are over 1000 connectors. If yours is there, the conversation is over. Build a cloud flow.

    Check 2. Does the target system have a documented REST API? If yes, and there is no premade connector, build a custom connector or use the HTTP action in a cloud flow. Still cloud. A custom connector is a one-time investment that pays back for years. A desktop flow against the same system needs babysitting forever.

    Check 3. Is the target a legacy desktop app, a Citrix session, a thick client with no API, or a website with no public API and aggressive anti-automation? Now you have a real desktop flow use case. Build it, but build it knowing the maintenance cost.

    The reason this matters is not aesthetics. It is failure modes. Cloud flows fail on API errors you can read and handle. Desktop flows fail because someone moved a window, changed a font scaling setting, or the machine running the unattended bot rebooted for patches at 3am. I wrote about this exact trade-off in RPA vs AI automation. Determinism is the whole point of RPA. The moment you put RPA in front of a system that already exposes a stable contract through an API, you are throwing away the determinism you came for and replacing it with selector fragility.

    One more pattern I see and want to call out. Hybrid flows are fine. A cloud flow that triggers a desktop flow only for the one screen that has no API is a perfectly clean design. What is not clean is a desktop flow that opens Outlook, opens SharePoint, opens Excel Online, all through the UI, when every single one of those has a first-party connector. That is not automation. That is a recorded macro pretending to be an enterprise solution. If you are prototyping flow logic and want a faster feedback loop without spinning up connectors every time, Thirty Days Running Ollama Locally for Automation Work covers where local AI actually saves time during that phase and where it falls short.

    The Microsoft Learn docs lay this out clearly under Power Automate documentation, but the guidance gets lost in the noise. The short version, from what I have built and watched others build: API first, connector second, custom connector third, desktop flow last. Reverse that order and you will spend more time fixing the automation than you saved by building it. And if your flows are starting to touch Dataverse directly, the Power Platform May 2026 Update has a few things worth turning on before you go further, particularly Power Fx UDTs hitting GA.

    Frequently asked questions

    When should I use a desktop flow instead of a cloud flow?

    Only when the target system has no connector and no documented API. That means a legacy desktop app, a Citrix session, a thick client, or a website with no public API. If a connector or REST API exists, build a cloud flow. No exceptions have held up in anything I have built or watched others build.

    Can I combine cloud flows and desktop flows?

    Yes, and the clean pattern is a cloud flow that orchestrates everything and triggers a desktop flow only for the one screen that has no API. The anti-pattern is a desktop flow driving Outlook, SharePoint, and Excel Online through the UI when all three have first-party connectors.

    Why do desktop flows need more maintenance than cloud flows?

    Because they fail on things that have nothing to do with your logic. A moved window, a font scaling setting, an unattended machine rebooting for patches. Cloud flows fail on API errors you can read, log, and handle in the flow itself.

    What if there is no premade connector for my system?

    Check for a documented REST API first. If one exists, build a custom connector or call it with the HTTP action from a cloud flow. That is a one-time investment that pays back for years. A desktop flow against the same system needs attention every time the UI shifts.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • RPA vs AI Automation for Enterprise Workflows

    RPA vs AI Automation for Enterprise Workflows

    RPA vs AI automation comparison for enterprise workflows

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published May 1, 2026

    The decision I keep watching teams get wrong: should this workflow be built with RPA or with an AI agent. The RPA vs AI automation debate gets framed as old tech versus new tech, which is the wrong frame entirely. They solve different problems. Picking the wrong one is how you end up with a fragile bot that needs babysitting or an agent that hallucinates its way through invoice approvals.

    I have built both inside a large org. Here is how I actually decide.

    Determinism and predictability

    RPA assumes the screen, the field, and the click path are the same every time. If the SAP transaction code is VA01 today and VA01 tomorrow, RPA wins. It will execute that path 10,000 times with zero variance.

    AI automation assumes variance is the input. The email phrasing changes, the PDF layout changes, the customer asks the same thing five different ways. An agent reasons over that variance. It is non-deterministic by design, which is a feature for unstructured input and a liability for structured execution.

    Rule of thumb I use: if I can write the decision tree on a whiteboard in 15 minutes, it is RPA work. If the decision tree has more than 30 branches and half of them are “it depends on the wording,” it is agent work.

    Cost per execution

    Dimension RPA (Power Automate Desktop) AI Agent (Copilot Studio)
    Per-run cost Near zero after license Roughly 1 message credit per turn, often 5 to 15 turns per task
    License model Per-bot or per-user attended/unattended Message packs, 25,000 messages per pack
    Scaling cost Linear with bot count Linear with conversation volume and tool calls
    Failure cost Bot stops, you fix it Agent confidently completes the wrong task

    RPA at 100,000 runs a month is basically free compute after the license. An agent at 100,000 runs is not. I have seen teams underestimate this by an order of magnitude because they tested with 50 runs and extrapolated linearly without counting tool calls and orchestration turns.

    Maintenance and brittleness

    RPA breaks when the UI changes. A vendor pushes a new SAP Fiori update, three selectors shift, your bot fails at 3am. I have lived this. The fix is usually 30 minutes, but you need someone on call who knows the bot.

    AI agents break differently. They do not fail loudly. They drift. The model provider updates, your prompt that worked last month now produces a slightly different output format, and downstream parsing silently fails. I wrote about this in my agentic workflow post. The failure mode is worse because users find out three days later when the wrong invoice gets paid. If you are building flows that sit underneath an agent, Power Automate error handling patterns that actually work will save you from the silent failures that surface weeks after go-live.

    RPA maintenance is reactive and obvious. Agent maintenance is proactive and requires evaluation infrastructure most teams do not build.

    What the work actually looks like

    This is the dimension nobody compares on. Look at the input.

    Structured input, structured output, no judgment needed: RPA. Copying 200 rows from a legacy system into a SharePoint list, kicking off a daily report, screen-scraping a vendor portal that has no API. Boring, repetitive, deterministic. Power Automate Desktop handles this all day. If you are still deciding whether to invest time in the broader platform, RPA is not the right tool for every repetitive task is worth reading before you commit to a build.

    Unstructured input, structured output, judgment needed: AI. Reading 500 supplier emails and extracting the PO number, classifying tickets by intent, summarizing a 40-page contract into five bullet points. This is where Copilot Studio or a custom agent earns its cost.

    The hybrid case is the most common one and the one most teams miss. The agent reads the email, extracts the structured fields, then hands off to an RPA bot or a cloud flow that executes the deterministic part. The agent is the reasoning layer. RPA is the execution layer. They are not competitors. They are stacked.

    Governance and auditability

    RPA logs are simple. Action ran, action succeeded, here is the screenshot. Auditors love this.

    AI agents need decision logs, not just execution logs. You need to capture why the agent picked tool A over tool B. Most teams I talk to are not logging this and will get caught when the first compliance review hits. I covered this in The Real Shift Is Not Faster Work It Is Who Owns the Decision. Based on what I have built, this is the gap that bites you 6 months in, not on day one.

    Choose RPA if / Choose AI if

    Choose RPA if: the input is structured, the path is deterministic, the volume is high, the cost per run needs to be near zero, and the system has no API. This is most legacy integration work.

    Choose AI automation if: the input is unstructured, the work requires classification or extraction or summarization, variance is the norm, and you have the evaluation discipline to catch silent drift.

    Choose both if: you have a real workflow. Most enterprise automation is hybrid. The line is not RPA versus AI. It is figuring out which layer does what.

    Frequently Asked Questions

    What is the difference between RPA vs AI automation for enterprise workflows?

    RPA is built for repetitive, predictable tasks where the process follows the same steps every time, while AI automation handles unstructured or variable inputs that require reasoning. They are not competing technologies but tools suited to different problems. Choosing the wrong one leads to either a fragile bot or an agent making confident mistakes.

    When should I use RPA instead of an AI agent?

    Use RPA when your process is consistent, rule-based, and can be mapped out as a clear decision tree. If the same fields, screens, or steps repeat thousands of times without variation, RPA will be faster, cheaper, and more reliable than an AI agent.

    How do I know if AI automation is worth the cost for my workflow?

    AI agents consume message credits per turn and most tasks require multiple turns, so costs scale quickly at high volumes. Before committing, calculate expected monthly runs and multiply by average turns per task, not just per conversation. Teams often underestimate this significantly when testing at small scale.

    Why does RPA break so often in enterprise environments?

    RPA relies on fixed UI selectors, so any interface update from a vendor can shift elements and cause the bot to fail. These failures are usually quick to fix but require someone familiar with the bot to be available when issues occur. Unlike AI agents, RPA fails loudly and immediately rather than silently producing wrong results.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • 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

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published April 19, 2026

    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.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Automating a Bad Process Makes It Fail Faster

    Automating a Bad Process Makes It Fail Faster

    By Halilcan Soran · Power Platform & AI Agents · Published April 15, 2026 · Updated August 8, 2026

    Updated August 2026 Added a section on how AI agents change the failure mode of undefined processes, and tightened the argument that process work and build work run in parallel, not in sequence.

    I came across a post from the Zapier blog about process improvement a while back, and it made a familiar point: most broken work is not actually broken work, it is 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 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. 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 no longer notice the decisions they make.

    The automation developer ends up being the first person to interrogate the process at that level of detail. Not by choice. The flow will not build until the ambiguity is resolved. You cannot write a condition on a field that sometimes exists and sometimes does not. You cannot route an approval to a role when the role changes based on factors nobody documented.

    This is not a Power Platform problem. I keep seeing it in every serious automation effort, both internally and from people I talk to at other orgs. The tool just makes the gaps visible faster than any process workshop 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 does not conform to any standard. Fields are free text where they should be choices. Dates arrive in three formats. Required fields are blank because the upstream system never enforced them. Your flow handles the clean case fine and breaks silently on everything else. Microsoft’s own guidance on error handling in Power Automate is good, but no amount of try-catch scopes will save you if nobody agreed what valid input looks like in the first place.

    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. Automate the majority answer and 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.

    AI Agents Do Not Fix This. They Hide It Better.

    This is the part that changed since I first wrote this post. In 2026 the default answer to a messy process is increasingly “put an agent on it.” I build Copilot Studio agents as part of my day job, and I ran into this internally more than once this year.

    A classic flow fails loudly when the process is undefined. It errors, it times out, it dead-ends. Annoying, but honest.

    An agent improvises. Give it a vague process and vague instructions and it will produce a confident answer anyway. It will route the request somewhere. It will summarize the exception instead of escalating it. The undefined process does not surface as a failure. It surfaces as plausible-looking output that nobody validates until something downstream is wrong.

    So the old rule got sharper, not weaker. Automating a bad process with a flow makes it fail faster. Automating a bad process with an agent makes it fail quietly. The second one is worse. If your process has ambiguity a human would resolve with judgment, you either encode that judgment as explicit instructions and guardrails, or you keep a human in the loop at that exact point. There is no third option where the model just figures out your org chart.

    Why Fixing the Process First Does Not Mean Waiting to Build

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

    That does not mean automate bad processes and hope. 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 the rule into the flow. Then you find the next gap.

    The first build is 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 beats most process workshops, because it came from 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 is not. The flow that handles the happy path and ignores edge cases is a prototype that revealed the real work. Ship it as final and you have automated the ambiguity along with the process.

    What I Actually Do Now

    My working loop, refined over the last couple of years of doing this full time:

    First, build the happy path fast and label it a prototype out loud, in writing, to everyone who will see it run.

    Second, log every ambiguity the build surfaces as a named decision with a named owner. Not “data quality issues.” One line per gap: this field, this branch, this approver, who decides.

    Third, refuse to encode a guess. If three people give three answers on an approval rule, the flow routes to a human until one answer wins. Same for agents, just stricter.

    Fourth, treat the second build as the real delivery. That is the one with the agreed rules, the exception paths, and the error handling that fails loudly instead of silently.

    It is slower than pretending the process document was accurate. It is much faster than rebuilding after the automation fails in front of the wrong person. If you have run this loop differently, I would genuinely like to hear it. Find me on LinkedIn.