Halilcan Soran

Category: Artificial Intelligence in Business

  • The Real Shift Is Not Faster Work It Is Who Owns the Decision

    The Real Shift Is Not Faster Work It Is Who Owns the Decision

    AI automation decision ownership shifting from human approvers to agents in enterprise workflows

    I came across a post from the Microsoft Power Platform Blog about intelligent apps, human leadership, and the new shape of work. The framing is fine, but the speed angle buries what I think is the actual shift happening right now. The real story is about ai automation decision ownership, not output volume. Two years ago a flow ran rules and a human approved the exceptions. Now the agent handles the exceptions and the human sets the policy the agent operates under. That is a completely different job.

    Speed Was Never The Interesting Part Of Automation

    Every automation pitch I have seen in the last five years leads with hours saved. It is the easiest metric to put on a slide. It is also the least interesting thing about a good automation.

    The flows I am proud of did not win because they were fast. They won because they removed a decision that did not need a human in the loop. A purchase order under a certain threshold. A leave request that matches a pattern. A ticket that routes itself based on content. The speed was a side effect of letting the process run without waiting for someone to click approve.

    Speed framing also makes everyone lazy about design. If the only goal is faster, you end up automating a bad process and shipping the same broken logic at ten times the throughput. I have written about this before. Bad process plus automation equals faster failure.

    The Decision Boundary Is What Actually Moved

    Here is the shift I keep seeing internally and hearing from people at other organisations.

    Old model: deterministic flow runs the rules, human handles anything weird. The human owns judgment. The flow owns execution.

    New model: agent handles the weird cases too, because it can reason about context, read the attachment, compare against policy, and make a call. The human no longer sits in the approval step. The human sits above the agent, writing the constraints it operates under.

    That is not a speed change. That is a decision ownership change. The human used to approve ten exceptions a day. Now the human writes the rules for how exceptions should be resolved and reviews a sample at the end of the week.

    Most teams I talk to have not internalised this yet. They still put the agent in the response step of a structured flow, which I already called out as not really agentic. The interesting version is when the agent sits in the decision layer and the deterministic steps execute what it decides.

    What This Changes About How I Build Flows And Agents

    When I build a flow now, I spend less time on the happy path and more time on what the agent is allowed to decide on its own.

    Concretely:

    • I write the policy first in plain language, not the flow. What can the agent approve without escalation. What must it always escalate. What does good look like. What does a bad outcome look like.
    • I design the tools the agent calls as if I am writing an API contract, because that is what I am doing. A tool returning done is useless. It needs to return the state the agent can reason about.
    • I build the escalation path before I build the automation path. If the agent is uncertain, where does it hand off. To whom. With what context.
    • I log the decisions, not just the executions. A flow run log tells me what happened. A decision log tells me why the agent chose what it chose, which is the only way to improve the policy.

    This is closer to writing Power Automate flows with an orchestration brain on top than it is to classical automation. If you are curious about that orchestration layer, Claude has been the most interesting model for this in my testing. Anthropic is shipping the kind of stateful reasoning this job actually needs.

    Stop Measuring Hours Saved Start Measuring Decisions Delegated

    If your AI project feels underwhelming even when it technically works, look at what you are measuring. Hours saved is a dashboard metric. Decisions delegated is an architecture metric.

    Some questions I ask when I review an automation now:

    • How many decisions used to need a human that no longer do.
    • What is the policy the agent is enforcing, and who owns that policy.
    • When the agent is wrong, how do we find out, and how fast do we update the policy.
    • What decisions are we deliberately not delegating, and why.

    None of these show up on a time-saved slide. All of them determine whether the automation holds up six months in.

    The job is not building flows anymore. The job is writing the operating constraints for something that makes judgment calls. That is a different skill, and I think the teams that figure this out early will look very different from the ones still counting hours. In my own experience, the projects that aged well are the ones where someone owned the policy, not the flow.

    Frequently Asked Questions

    What is AI automation decision ownership and why does it matter?

    AI automation decision ownership refers to who or what holds responsibility for making judgment calls inside a workflow. It matters because modern AI agents can now handle exceptions and reasoning tasks that previously required a human approver, fundamentally changing the role people play in automated processes.

    How do I know if my automation is truly agentic or just a faster rule-based flow?

    A good indicator is where decisions actually happen. If a human or a rigid rule set still handles every exception and the AI only executes predefined steps, the workflow is not truly agentic. An agentic setup puts the AI in the decision layer, with deterministic steps carrying out what it concludes.

    Why does automating a bad process lead to worse outcomes?

    Automation removes the friction that sometimes forces people to notice problems. When a flawed process runs faster and at higher volume, errors multiply at the same rate as the throughput, making the underlying issues harder to catch and more costly to fix.

    When should I move a human out of the approval step in an automated workflow?

    A human can move out of direct approvals when the decision follows a consistent pattern that can be expressed as clear policy constraints. The better use of human judgment at that point is writing and periodically reviewing those constraints, rather than approving individual cases one by one.

    This post was inspired by Intelligent apps, human leadership, and the new shape of work via Microsoft Power Platform Blog.

  • SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint lists for power platform apps backend architecture decision

    There is a pattern I keep seeing on LinkedIn and in conversations with people at other organisations. A team starts a new Power Platform project, someone labels it ‘enterprise’, and suddenly the backend discussion jumps straight to Dataverse. No one questions it. Licensing gets justified in a spreadsheet, premium seats get budgeted, and six weeks later the solution is a list of 4000 records with a status column and three lookup fields. That is the moment I want to push back. For a big chunk of internal work, SharePoint lists for power platform apps are still the right call, and treating that choice as amateur hour is costing teams real time and money.

    Why SharePoint Lists Keep Getting Dismissed Unfairly

    The dismissal usually comes from two places. First, the word SharePoint carries baggage from the 2013 era that has nothing to do with what Lists actually is in 2026. Second, Dataverse gets sold as ‘the proper enterprise choice’ in every Microsoft deck, so picking anything else feels like admitting you cut corners.

    Neither of those is an engineering argument. They are vibes.

    In practice, a modern SharePoint list gives you a REST and Graph API, column-level validation, versioning, item-level permissions if you really need them, native integration with every Power Platform connector, and a UI that business users can actually open and fix when something looks off. You get Entra ID authentication for free. DLP policies cover it. The audit log flows into the same Purview tenant everything else does. For an internal request tracker, an onboarding checklist, a small approval queue, or a reference table that three flows read from, that is the whole job.

    The Workloads Where SharePoint Is Genuinely the Right Answer

    I am not arguing SharePoint wins everywhere. I am arguing it wins for a specific and very common shape of work.

    If the app is an internal tool, used by under a few hundred people, with a data volume that will never credibly pass 20 or 30 thousand items in any single list, and a schema that fits cleanly into flat records with a handful of choice and lookup fields, you are in SharePoint territory. Registrations, comms sign-offs, small approval workflows, asset inventories, internal request forms, training trackers, audit checklists. This is the bread and butter of Power Platform inside any large organisation.

    Building on a list for that kind of workload is faster in almost every dimension. You spin up the schema in minutes. Makers on your team can read and edit the data directly in the browser without a model-driven app wrapper. Your Power Automate flows use the standard SharePoint connector, which means no premium licence for the thousand people who happen to trigger a flow indirectly. That last point alone saves real budget. I have written before about how licensing shapes architecture choices in enterprise environments, and this is one of the clearest examples.

    The Real Limits You Need to Design Around

    SharePoint lists are not magic. They have hard edges, and you need to know them before you commit.

    The 5000 item view threshold is the one everyone quotes, and it is real, but it is a view and query limit, not a storage limit. A list can hold millions of items. You work around the threshold with indexed columns, filtered views, and delegable queries in Power Apps. If you are careful with your delegation, a list with 50,000 items performs fine for the usage patterns most internal apps actually have.

    Throttling is the other one. The SharePoint connector has its own limits, and if you are running a flow that hammers a list in an Apply to Each loop at full concurrency, you will get throttled. Same story I covered in the throttling post. Drop concurrency, batch your reads, and stop treating the list like a transactional database.

    Where SharePoint genuinely falls over is relational complexity. More than two or three lookups deep and you are building joins in Power Automate, which is painful to maintain. Row-level security beyond basic item permissions gets ugly fast. Calculated columns are limited. And if two users edit the same item in the same second, you can get conflicts the platform does not resolve gracefully. This is also where why Power Automate is still worth learning in 2026 becomes relevant — knowing how to structure flows around list limitations is a skill that pays off repeatedly.

    When to Actually Move to Dataverse

    Dataverse earns its licence cost when the workload has specific characteristics. Genuine relational depth with many-to-many relationships you actually traverse. Role-based security that needs to be enforced at the data layer, not the app layer. Business rules and calculated fields that are part of the data contract. Plugins, server-side logic, or integration with Dynamics. Auditing at the field level for compliance. Transactional guarantees where a failed write must roll back cleanly.

    If your project has three or more of those, Dataverse is the right choice and the licensing conversation is easy to win because the alternative is building those features yourself and maintaining them forever.

    If your project has none of them, and you are about to spend eight weeks justifying premium seats for 400 people so you can store a status column on 4000 records, stop. Build it on a list. Ship it next week. Spend the saved budget on something that actually needs it. And before you wire any intelligence layer into whatever you build, it is worth reading Adding Copilot to Your Power App Is Not the Same as Making It Smarter — the backend choice and the AI layer choice follow the same logic.

    The backend choice is an engineering decision, not a status symbol. I write more about these kinds of trade-offs on my LinkedIn if this is the kind of call you are wrestling with right now.

    Frequently Asked Questions

    When should I use SharePoint lists for Power Platform apps instead of Dataverse?

    SharePoint lists are a strong fit when your app is internal, used by fewer than a few hundred people, and will never exceed tens of thousands of items in a single list. Common examples include approval queues, request forms, training trackers, and asset inventories where a flat schema with a few lookup fields covers everything you need.

    Why does using SharePoint as a Power Platform backend save money on licensing?

    Power Automate flows that connect to SharePoint use the standard connector, which does not require a premium licence. In large organisations where thousands of users might trigger a flow indirectly, avoiding premium connector requirements can add up to significant budget savings compared to a Dataverse-backed solution.

    What are the security and governance features available with SharePoint lists?

    Modern SharePoint lists authenticate through Entra ID and are covered by your organisation’s DLP policies. Audit logs feed into the same Purview tenant as your other Microsoft 365 services, so governance and compliance requirements are met without additional configuration.

    How do I know if Dataverse is actually necessary for my Power Platform project?

    If a solution is genuinely enterprise in scale, involving complex relational data, high record volumes, or advanced role-based security requirements, Dataverse earns its place. However, if the data model is a few flat lists with simple lookups and the user base is a small internal team, reaching for Dataverse by default adds cost and complexity without a clear engineering benefit.

  • If You Are Starting Copilot Studio in 2026 Skip the Chatbot Tutorials

    If You Are Starting Copilot Studio in 2026 Skip the Chatbot Tutorials

    Getting started with Copilot Studio 2026 using generative orchestration instead of topics

    I keep running into people getting started with Copilot Studio in 2026 who spent their first two weeks building a topic tree with trigger phrases and a node-by-node dialog flow. Then they ask me why their agent feels rigid and why every new question breaks something. The answer is not that they built it badly. They learned the wrong paradigm from tutorials written three years ago.

    If you are starting today, skip the chatbot tutorials. Go straight to a generative orchestration agent with a couple of tools and knowledge sources. That is how real agents are being built now.

    Why the 2023 Copilot Studio learning path is actively misleading in 2026

    The classic learning path walks you through creating a topic, adding trigger phrases, building a dialog tree with question nodes, conditions, and variables, then testing it with the exact phrases you wrote. It feels productive because you see progress quickly. It is also teaching you a way of thinking that does not scale past an FAQ bot.

    Microsoft itself has de-emphasised this path. Generative orchestration is the default for new agents. Topics still exist and still have their place, but as guardrails for specific flows that must follow a strict script, not as the primary way to build conversation.

    The problem with learning topics first is unlearning them later. People who start with trigger phrases end up writing dozens of them trying to catch every variation a user might type, then wonder why the agent still misroutes at the edges. Your Copilot Studio Agent Passed Every Test and Still Failed in Production explores exactly this kind of failure. Generative orchestration does not eliminate this, but it changes the shape of the problem entirely.

    The four things that actually matter when you start today

    When someone joins the team and asks where to begin with Copilot Studio, I tell them to focus on four things before anything else.

    Instructions. The system prompt is where most of the agent’s behaviour comes from now. Learning to write clear, specific, scoped instructions is more valuable than learning the node editor. Bad instructions cause instruction drift the moment real data hits the agent.

    Knowledge sources. Connecting a SharePoint site, a Dataverse table, or a public website and understanding how the agent grounds answers in them. This is where the actual information lives. Most agents do not need a dialog tree, they need good grounding.

    Tools. A tool is a Power Automate flow, a connector action, an MCP server, or a prompt. Learning how to design tools so the agent can call them reliably is the real skill. Returning a status of done is not enough. The agent needs structured output it can reason about.

    Orchestration behaviour. Understanding that the LLM picks which tool to call, in what order, and how to handle the result. You are not drawing the flow. You are writing instructions and designing tools so the LLM can draw the flow at runtime. If you are deciding whether Copilot Studio is even the right tool for what you are building, Copilot Studio Is Not Always the Answer is worth reading before you go further.

    A first build that teaches you the right mental model

    Pick a small real scenario. Something like: surface open tickets assigned to the current user and let them add a comment. Not a chatbot. An agent with a job.

    Create a new agent in Copilot Studio with generative orchestration enabled. Skip topics entirely for this first build. Write clear instructions describing what the agent does, what it does not do, and how it should respond when it cannot help.

    Add one knowledge source. A SharePoint site or a Dataverse table works well. Ask it questions against that knowledge and watch how it grounds.

    Add two tools. One Power Automate flow that reads data, one that writes. Make sure both return structured output, not just a success flag. Test what happens when the write fails. If the agent does not know it failed, fix the tool, not the agent.

    That is the entire first build. No trigger phrases. No dialog tree. No variables you manage manually. You will learn more in a week of this than a month of the traditional tutorial path.

    What to learn next once your first agent works

    Once that agent behaves reliably, then learn topics. Use them for the narrow cases where you need a deterministic script. Identity confirmation. Regulated disclosures. Multi-step forms with strict validation. Topics are good at this. They are bad as the primary way to build an agent.

    After topics, learn evaluation. Not just output testing. Behavioural testing. Does the agent handle incomplete questions, mid-conversation intent switching, and edge case inputs the way you expect? Most agentic workflows that feel intelligent in a demo turn out to be just fancy if/then logic in a trench coat when real users hit them. This is the single skill that separates agents that pass a demo from agents that survive production.

    Then learn MCP, custom connectors, and multi-agent orchestration. By that point you will have the mental model to evaluate whether you actually need them or whether a simpler design solves the problem.

    The fastest way to be useful with Copilot Studio in 2026 is not to learn every feature. It is to learn the four things above, build one real agent, and resist the pull of outdated tutorials that still dominate the first page of search results.

    Frequently Asked Questions

    How do I get started with Copilot Studio in 2026 without wasting time on outdated tutorials?

    Skip the classic topic-and-trigger-phrase approach and go straight to building a generative orchestration agent. Focus on writing clear instructions, connecting knowledge sources, and designing reliable tools rather than learning the node-based dialog editor.

    What is generative orchestration in Copilot Studio and why does it matter?

    Generative orchestration is now the default approach for new agents in Copilot Studio, where the agent uses AI to handle conversation flow rather than following a rigid dialog tree. It reduces the need to manually write dozens of trigger phrases and scales far better than the older topic-based model.

    Why does my Copilot Studio agent feel rigid and break when users ask unexpected questions?

    This usually happens when the agent is built around a topic tree with trigger phrases, which only handles the exact variations you anticipated. Switching to a generative orchestration approach with well-written instructions and grounded knowledge sources makes the agent much more flexible.

    When should I still use topics in Copilot Studio?

    Topics are still useful when a specific flow must follow a strict, predictable script, such as a regulated process or a form-style interaction with no variation. They work best as guardrails for those edge cases rather than as the foundation of the entire agent.

  • Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages server side logic AI code generation with GitHub Copilot and Claude Code CLI

    Power Pages server-side logic has always been where the low-code promise quietly falls apart. You get a clean design studio, drag-and-drop layouts, reasonable out-of-the-box forms. Then someone asks for server-side validation that cannot safely run in the browser, a secure external API call where the key can never touch the client, or a multi-table transaction that needs to complete before a Dataverse record is committed. And these three new skills are for modern single-page application (SPA) Power Pages sites specifically — not the classic Liquid-templated architecture — which matters if your audience spans both worlds. And suddenly you’re either writing it from scratch by hand, spending an afternoon in documentation, or handing it off to someone on a proper dev team and waiting. I came across a post from the Microsoft Power Platform Blog about three new agentic code skills for the Power Pages plugin, and it hit on something I’ve been thinking about for a while: the ceiling for what a single automation developer can ship in Power Pages without a dedicated dev team behind them just moved.

    What Server-Side Logic in Power Pages Actually Means and Why It Was Always the Hard Part

    Power Pages is a low/no-code portal builder sitting on top of Dataverse. The studio handles most of the front-end work reasonably well. But portals have always had a split personality. There’s what you can configure visually, and then there’s the layer underneath. For modern SPA-style Power Pages sites, that means server-side JavaScript endpoints that handle validation, secrets, and external API calls; Cloud Flow connections for backend automation; and integrations with systems that can’t be wired directly from the browser. That second layer is not configuration. It is code. And it requires context about your specific environment to write correctly.

    This is why generic AI code generation has never worked well here. Asking an LLM to write you a server-side endpoint without knowing your Dataverse schema, your table structure, or your page context produces something that compiles and fails as soon as you wire it to real data. The model doesn’t know your environment. You end up doing the real work yourself anyway, just with a plausible-looking starting point that may or may not match reality.

    What These Agentic Code Skills Actually Do When You Run Them

    The specific thing that matters here is scope. These are not general-purpose code suggestions. The plugin is grounded in your actual Power Pages site. It understands your tables, your site settings, your page context — because architect agents analyze your actual code and query your Dataverse environment before generating anything. Then they propose specific changes for your review before anything is applied. That propose-then-approve loop is not a limitation; it is a selling point. You stay in control of what lands in your site. When you describe the server-side behaviour you need, the generated code is scoped to your environment, not a hypothetical portal that shares no properties with yours.

    That is the distinction most people will miss when they skim the announcement. The three new skills are /add-server-logic, which generates server-side JavaScript endpoints for validation, secrets management, and cross-entity operations; /add-cloud-flow, for connecting backend automation; and /integrate-backend, for wiring in external systems. These join six existing skills in the plugin — nine total. Each one is pulling from what the plugin already knows about your site structure. The output is contextually aware in the same way that Claude operating with good tool design returns useful results because it has real signals to work with, not because the model is smarter in isolation. I wrote about this in the context of agentic workflows generally: tool design is an API design problem, and what makes these skills interesting is that Microsoft has done that tool design work to give the model actual environmental context to reason against. If you want to go deeper on how Claude functions as that reasoning layer in enterprise contexts, Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now covers the architecture side of that in more detail.

    The Claude Code CLI path is worth calling out specifically. If you’re already working with Claude for orchestration or code tasks outside the Power Platform, having it also handle your Power Pages server-side work inside the same workflow is practically useful. You’re not switching contexts or tools.

    The Specific Scenario Where I Would Use This First

    The scenario I keep running into internally is validation logic that cannot run client-side — business rules that reference data from other tables, check against external state, or need to complete before a Dataverse write is committed. That is exactly the /add-server-logic case: a server-side JavaScript endpoint that runs the check first, keeps any secrets out of the browser, and returns a clean result to the form. Describing that condition and getting generated code that already references your actual table names and schema cuts the build time significantly. That’s the first thing I’d point this at.

    The second would be secure external API calls where credentials cannot touch the browser at all. You describe the integration — what the endpoint expects, what you need back — and /add-server-logic generates an endpoint that already references your actual environment. That is a different kind of useful than autocomplete, and it removes a class of security mistake that comes from passing keys through the client.

    Where This Still Has Limits and What You Still Need to Know Yourself

    I want to be direct about this because I’ve seen the same pattern play out with AI-assisted flow building in Power Automate: faster to working and closer to production are not the same thing. Generated server-side code that looks correct can still have permission boundary issues, silent failures on edge case inputs, or endpoint logic that works on the happy path and throws an unhandled error when a value comes back null from Dataverse. The model generates against your environment, but it does not run your QA process.

    You still need to understand how Power Pages table permissions actually interact with Web API calls. You still need to know what a plugin execution context looks like and where it can fail. If you’re purely vibe building with generated code and no mental model of what’s running underneath, you’ll ship something that passes your own demo and fails on the first real user submission. This is the same problem that comes up when adding Copilot to a Power App gets treated as a shortcut around understanding what’s actually running under the surface. The same principle I keep coming back to on my own work applies here: the AI is the generation layer, you are still the verification layer.

    That said, for an automation developer who already understands the Power Pages architecture and just needs to move faster on the server-side code parts, this is genuinely useful. The ceiling for what one person can build without a dedicated dev team behind them has moved. I’ll be testing this on the next portal build that needs real server-side work, and I’m curious how much of the scaffolding holds up in practice.

    Frequently Asked Questions

    How do I generate server-side logic for Power Pages using AI?

    You can use the three new agentic code skills available through the Power Pages plugin, which work with tools like GitHub Copilot or Claude Code CLI. Unlike generic AI tools, these skills are grounded in your actual site environment, so the generated server-side endpoints, Cloud Flow connections, and backend integrations are written against your specific Dataverse schema and site structure rather than a generic example. Note that these three skills are designed for modern SPA-style Power Pages sites, not classic Liquid-based portals.

    What is the difference between Power Pages server-side logic and front-end configuration?

    Front-end configuration in Power Pages covers layouts, forms, and visual design handled through the studio. For modern SPA-style Power Pages, server-side logic refers to the layer underneath the client: JavaScript endpoints for validation and external calls, Cloud Flow integrations for backend automation, and connections to external systems. This layer is not configuration — it is code that requires environment-specific context to write correctly. This second layer requires actual coding knowledge and environment-specific context to get right.

    Do these Power Pages agentic code skills work with classic Liquid-based sites?

    No. The three new skills — /add-server-logic, /add-cloud-flow, and /integrate-backend — are designed for modern single-page application (SPA) Power Pages sites, not classic Liquid-templated portals. If your Power Pages work is primarily in the classic architecture, these skills do not apply to your current stack.

    When should I use AI-generated plugin logic in Power Pages instead of writing it manually?

    AI-generated plugin scaffolding is most useful when you need to enforce business rules on record creation or updates and want a working starting point built around your actual Dataverse tables. It reduces the time spent in documentation and removes the dependency on a dedicated development team for straightforward but environment-specific server-side requirements.

    This post was inspired by Build your server-side logic with AI: new Power Pages Agentic Code skills via Microsoft Power Platform Blog.

  • Why Power Automate Is Still Worth Learning in 2026

    Why Power Automate Is Still Worth Learning in 2026

    Developer reviewing Power Automate flow structure on screen, representing why you should learn Power Automate in 2026

    I keep hearing a version of the same idea from people just getting into the Microsoft stack. Why spend time learning Power Automate when you can describe what you want to a Copilot Studio agent and have it figure out the execution? The assumption behind that question is that Power Automate is scaffolding you work around, not something you need to understand. That assumption is costing people real time. If you want to learn Power Automate in 2026, the argument for doing it has not weakened. It has gotten stronger.

    The ‘Just Use an Agent’ Shortcut Has a Hidden Cost

    Copilot Studio agents and AI-assisted flow building have made it faster to get something working. That part is real. The problem is that faster to working and closer to production are not the same thing.

    I have seen this pattern repeatedly. Someone builds an agentic workflow, the demo runs cleanly, and then it breaks in production in a way they cannot explain. Not because the agent reasoning was wrong. Because the underlying flow had no retry logic, the connection was using a shared credential that hit a rate limit under load, or a step was silently failing and passing a null value forward. The agent kept going. The result was wrong. Nobody knew until downstream.

    I wrote about this dynamic in the context of agentic workflows before. An agent that generates a confident-sounding response for a task that did not complete destroys user trust faster than almost any other failure mode. The agent is the reasoning layer. Power Automate is still the execution layer. If you do not understand the execution layer, you cannot debug what the reasoning layer is telling you went wrong.

    What Power Automate Actually Does That Nothing Else Replaces

    Power Automate is where things actually run inside a Microsoft-stack enterprise. SharePoint events, Teams messages, Dataverse writes, approval routing, HTTP callouts to external APIs, scheduled jobs, document generation triggers. The connectors, the authentication, the retry behaviour, the action limits. All of it lives here.

    Copilot Studio can call a Power Automate flow. An AI Builder model can feed into one. An agent can trigger one. But the flow is what actually touches the system of record. When something goes wrong at 2am and you are looking at a run history, you need to know what you are reading. You need to know whether a 429 error is platform-level throttling or connector-level throttling, because the fix is different. I spent a full post on exactly that distinction and it is still one of the most common misdiagnoses I hear about. Applying the wrong fix because you conflated the two layers is a common reason throttling problems persist after troubleshooting.

    That kind of mechanical understanding does not come from describing what you want to an agent. It comes from building flows, watching them fail, and understanding why. The Microsoft Learn documentation for Power Automate covers the connector model and trigger types well, but the intuition for where things go wrong only comes from time in the tool.

    What I Would Focus on Learning First

    If I were starting today, I would ignore the visual polish and go straight to the things that bite you in production.

    Trigger types first. Automated, scheduled, and instant triggers behave differently. Understanding which one is firing your flow, and why, is foundational. A flow that should run once per item can run multiple times if the trigger is misconfigured and the conditions are wrong.

    Then connector authentication. Service principal vs. shared connection vs. connection reference. In enterprise environments, shared personal connections on flows that other people own is a support incident waiting to happen. Connection references and service principals exist for a reason. Learn them before you need them.

    Then error handling. Specifically, configure run after on every branch that matters. A flow that has no error path is a flow that fails silently. Silent failures in automation are worse than loud ones. I have written about how automated processes have no equivalent to a human noticing something feels off and escalating. Automating a bad process just makes it fail faster, and the exception silently propagates instead. Configure run after is the closest thing Power Automate gives you to that instinct.

    Apply to each concurrency settings come next. The default behaviour is sequential. Changing it to parallel speeds things up and introduces race conditions if you are not careful. Knowing when to use which, and how to tune it, matters the moment you are processing more than a handful of records.

    Where This Knowledge Starts Paying Off in More Advanced Work

    Once you understand how flows are structured and where they fail, everything built on top of them becomes more readable. Copilot Studio action steps that call flows stop being black boxes. You can look at what a cloud flow is doing inside an agent and understand whether the tool response is reliable. You can design the tool contract properly instead of returning a status that gives the agent nothing to evaluate.

    The people I talk to at other organisations who are building agentic workflows that actually hold up in production share one thing. They did not skip the foundation. They know what happens inside the flow the agent is calling. They know what a bad intermediate result looks like and they have built the error paths to catch it before it propagates.

    The practitioners skipping straight to orchestration are building things that look impressive in demos and require constant firefighting after launch. That gap in reliability traces back to the same place every time. They do not know the execution layer well enough to control it.

    Learning Power Automate in 2026 is not about catching up on something old. It is about having the mechanical understanding that makes everything else you build on the Microsoft stack actually reliable. That foundation is still the thing that separates flows that work from flows that work until they do not.

    Frequently Asked Questions

    Is it still worth it to learn Power Automate in 2026?

    Yes, learning Power Automate in 2026 remains valuable because it is the execution layer for almost everything that runs inside a Microsoft-stack enterprise. AI tools and agents can help you build flows faster, but you still need to understand how flows work to debug failures, handle errors, and get workflows into production reliably.

    What is the difference between Copilot Studio and Power Automate?

    Copilot Studio handles the reasoning and decision-making layer, while Power Automate is the execution layer that actually interacts with systems like SharePoint, Dataverse, and external APIs. An agent can trigger a flow, but the flow is what performs the real work and touches the system of record.

    Why does my Power Automate flow work in testing but fail in production?

    Common causes include missing retry logic, shared credentials hitting rate limits under load, or steps that silently fail and pass null values forward. These issues are easy to miss during demos but become serious problems at scale, which is why understanding flow structure matters beyond just getting something running.

    When should I learn Power Automate instead of relying on AI-generated flows?

    You should invest in learning Power Automate when you are responsible for workflows that need to be reliable in production, not just functional in a demo. If you cannot read a run history or diagnose a throttling error, you will struggle to fix failures that AI tooling alone cannot explain.

  • 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.

  • Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now

    Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now

    Most of the conversation around Claude in enterprise automation circles is stuck on the wrong question. People are comparing it to GPT-4o or Gemini as a text generator, debating which one writes better emails or summarises documents more accurately. That framing completely misses what makes Claude enterprise automation orchestration genuinely interesting right now.

    The practitioners I talk to who are getting real results are not using Claude as a chatbot. They are using it as the reasoning layer that decides what to do next in a multi-step, stateful workflow. That is a different problem than answering a question, and it changes everything about where Claude fits in your architecture.

    The chatbot framing is getting in the way

    When a team says they want to “add Claude” to something, the default mental model is a chat interface. User sends message, model replies. Maybe it calls a tool or two. That is not orchestration. That is a smarter input box.

    Orchestration is what happens when you need a model to receive a complex goal, break it into sequenced steps, call different tools at different points, evaluate intermediate results, and decide whether to continue, retry, or escalate. The model is not answering a question. It is managing execution across a process that has state, has branching conditions, and has consequences if it goes wrong.

    I wrote about this problem directly in the post on agentic workflows. The LLM is not the agent. The LLM is the reasoning layer. If you treat them as the same thing, you end up bolting a model onto the response step of what is really just a structured flow. That is not orchestration. That is decoration.

    What makes Claude specifically interesting for orchestration logic

    Two things stand out when I look at how Claude behaves in multi-step contexts compared to other models at similar capability levels.

    First, instruction following under load. When you give Claude a detailed system prompt with conditional logic, constraints, tool-use rules, and output format requirements, it holds those instructions across a long session more reliably than most alternatives. With other models I have tested, instruction drift starts showing up once you push past a few thousand tokens of context. Claude handles longer, more complex prompts without silently dropping constraints mid-execution. For orchestration, where the system prompt is essentially your process logic written in natural language, that matters a lot.

    Second, the extended context window is not just about volume. It is about statefulness. A workflow that processes a contract, then a set of approval records, then a policy document, then makes a decision that references all three needs a model that can hold all of that in scope simultaneously. Losing context partway through an orchestration run means the model makes decisions with incomplete information. It does not know it has incomplete information. It proceeds confidently anyway. I have seen exactly this failure mode in Copilot Studio agents, where silent context loss leads to confident-sounding responses for tasks that were never properly evaluated.

    Where I would actually slot this into a Power Platform architecture

    I would not replace the existing orchestration layer in a Power Automate flow with a Claude prompt. That is not the use case. Power Automate is still the right place for deterministic, sequential steps with connectors, triggers, and error handling you can inspect.

    Where Claude earns its place is in the decision layer that sits above or between those steps. Think of a workflow that processes incoming requests, where each request has variable structure, ambiguous intent, and routing logic that depends on context that changes week to week. A hard-coded set of conditions in Power Automate will break the moment the business logic shifts. A Claude orchestration layer that reads the request, evaluates the current context loaded from Dataverse, and decides which downstream flow to invoke handles that variability without you rewriting conditions every time.

    In practice, I would build it as a Copilot Studio agent backed by Claude through a custom connector or direct API call, where Claude handles the reasoning and routing logic and Power Automate handles execution of the discrete steps. The agent decides. The flows act. The separation matters because it keeps your execution logic testable and your reasoning logic flexible. Before wiring any of this together, it is also worth auditing what adding Copilot to an existing app actually changes versus what it just surfaces differently.

    The governance piece from the post on enterprise Power Platform applies here too. Calling an external Anthropic API endpoint means your orchestration reasoning is leaving the tenant. That is an audit trail split and a DLP conversation you need to have before you build, not after.

    The honest constraints before you redesign anything

    Claude is not a free variable. Longer context windows mean higher token costs per run, and orchestration workflows that run hundreds of times a day will surface that quickly in billing. Model latency at high context volumes is also real. If your process requires sub-second decisions, this is not your tool.

    The other constraint is testability. When your orchestration logic lives in a system prompt rather than a flow diagram, reproducing a failure is harder. The model made a bad routing decision on Tuesday afternoon. Why? You need logging at the prompt level, not just at the action level. Most teams I see building this way have not set that up, and they hit the same silent failure problem I described in the Copilot Studio testing post: everything looks fine until a real user finds the edge case.

    Claude as an orchestration brain is a genuinely different capability than what most teams are building with today. The question is not whether it is smarter than the last model. The question is whether your architecture is designed to use a reasoning layer at all, or whether you are still just looking for a better chatbot to put at the front of a process that was never designed to be orchestrated.

    Frequently Asked Questions

    What is Claude enterprise automation orchestration and how is it different from using Claude as a chatbot?

    Claude enterprise automation orchestration means using Claude as the reasoning layer that manages multi-step workflows, rather than as a simple question-and-answer interface. Instead of responding to single prompts, Claude receives a complex goal, breaks it into steps, calls tools, evaluates results, and decides how to proceed. This requires stateful, branching logic that goes well beyond what a chat interface is designed to handle.

    Why does instruction drift matter when using an LLM for workflow orchestration?

    In orchestration, your system prompt acts as the process logic for the entire workflow, so if the model quietly forgets constraints or rules mid-execution, the whole process can break or produce incorrect outcomes. Some models begin losing adherence to instructions as context grows, which is a serious problem in long-running enterprise workflows. Consistency across extended sessions is one of the key reasons practitioners favour certain models for this use case.

    When should I use an LLM as an orchestration layer instead of a traditional workflow tool?

    An LLM-based orchestration layer becomes valuable when your workflow involves conditional reasoning, ambiguous inputs, or decisions that depend on synthesising information from multiple sources rather than following a fixed rule set. If your process logic can be fully mapped in advance and never changes based on context, a traditional workflow tool is likely simpler and more reliable. The LLM adds value where judgment and adaptability are required at execution time.

    How does a large context window improve multi-step enterprise workflows?

    A large context window allows the model to hold all relevant documents, intermediate results, and prior decisions in scope at once, rather than losing earlier information as the workflow progresses. This matters in processes that require a final decision to reference multiple earlier inputs, such as reviewing a contract alongside approval records and a policy document. Losing that context mid-run can lead to decisions that are inconsistent with earlier steps in the same workflow.

  • 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

  • Adding Copilot to Your Power App Is Not the Same as Making It Smarter

    Adding Copilot to Your Power App Is Not the Same as Making It Smarter

    Microsoft published a post this week about making business apps smarter by embedding Copilot, app skills, and agents directly into Power Apps. The features are real and some of them are genuinely useful. But I keep seeing teams read announcements like that and immediately open their existing apps to start wiring things in. That is where it goes wrong. Adding Copilot to Power Apps does not make the app smarter. It makes the AI visible. Those are different things.

    What App Skills and Agent Integration Actually Do Under the Hood

    When you expose a Power App as an app skill or embed a Copilot Studio agent into a canvas app, you are giving the AI a surface to operate on. The agent can read context from the app, trigger actions, and return responses into the UI. In theory, the AI bridges what the user needs and what the app can do.

    In practice, the agent is only as capable as what you hand it. It reads data from your app’s data sources. It calls the actions you have defined. It interprets user intent against the topics and instructions you have written. If your data model is inconsistent, your actions are incomplete, or your process logic has gaps, the agent does not compensate for any of that. It just operates on top of it and returns confident-sounding responses anyway.

    I wrote about this problem in a different context when covering why Copilot Studio agents fail in production. Silent action failures are one of the nastiest issues: the agent completes its response, the user thinks something happened, nothing actually did. That risk does not disappear when you move the agent inside a Power App. If anything, it gets harder to spot because users expect the app to be reliable.

    Why the Data Model and UX Structure Matter More Than the AI Feature

    Most Power Apps I have seen built inside large organisations were designed around a specific, narrow workflow. The data model reflects decisions made at the time of build, often under time pressure, often by someone who is no longer on the team. Fields are repurposed. Status columns hold values that mean three different things depending on which team is using them. Lookup tables have orphaned records nobody cleaned up.

    When you put an agent on top of that, the agent queries this data and tries to give useful answers. The answers will be coherent. They will not be correct. Not reliably.

    The UX structure compounds this. Canvas apps built for point-and-click navigation do not automatically become good AI surfaces. If a user can ask the agent to update a record, but the app’s own form has fifteen required fields and three conditional rules that only run client-side, you now have a conflict between what the agent can do via a Power Automate action and what the app enforces through its UI. One of them will win. It will not always be the right one.

    This is the same argument I made about automating a bad process. The automation does not fix the process, it executes it faster and more consistently, including the broken parts. Embedding AI into a poorly structured app works the same way.

    What I Check Before Wiring Any Agent Into an Existing App

    Before I connect anything to a Copilot Studio agent or enable app skills on an existing Power App, I go through a short audit. Not a formal document. Just four questions that save a lot of cleanup later.

    • Is the data model clean enough to query? If the same concept is stored in three different columns across two tables with inconsistent naming, the agent will surface that inconsistency directly to the user. Fix the model first.
    • Are the actions the agent can trigger complete and safe? Every Power Automate flow an agent can call needs proper error handling and a defined failure response. Silent failures inside agent topics are a known problem. If the flow does not return a clear success or failure, the agent cannot respond accurately.
    • Does the app enforce rules that the agent needs to know about? If business logic lives only in Power Fx expressions inside the app’s forms, the agent does not see it. Validation that matters needs to exist at the data layer or inside the flows the agent calls.
    • Is the process the app supports well-defined enough to describe to an AI? If I cannot write a clear system prompt describing what the agent should and should not do in this app, the process is not ready. Ambiguity in the process becomes ambiguity in agent behaviour.

    When Embedding AI in a Power App Is Worth It and When It Is Not

    There are genuinely good cases for this. An app where users regularly need to find records across complex filters is a reasonable candidate. Surfacing a conversational shortcut to navigate a large dataset, trigger a common action, or get a summary of a record without clicking through multiple screens can reduce real friction. I have seen it work well when the underlying data is clean and the scope of what the agent can do is narrow and explicit.

    The cases where it is not worth it yet are more common. An app with inconsistent data. A process with unresolved exceptions. A UX that was never designed with AI interaction in mind. In those situations, embedding an agent creates a new layer of support burden without a proportional benefit.

    I also want to be direct about something I mentioned in my post on when Copilot Studio is the wrong choice: not every interaction benefits from being conversational. Some things in a Power App are faster as a button. The AI control is not always an upgrade on a well-placed filter or a clear form layout.

    Connect with Halilcan Soran on LinkedIn for more insights on Power Apps and AI integration.

  • 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.