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.

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.

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.

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.

Why does my Copilot Studio agent testing pass in demos but fail in production?

Most Copilot Studio agent testing is built around ideal user inputs and predictable conversation paths, which do not reflect how real users actually behave. In production, users ask incomplete questions, switch intent mid-conversation, and use the agent in unintended ways that no demo ever surfaces. Testing needs to go beyond the happy path to catch these edge cases before go-live.

What are the most common failure modes in Copilot Studio agents?

The three patterns that appear most often are topic misrouting when user phrasing falls between two intents, action failures that complete silently without triggering any error or fallback, and prompt instructions that break down when they encounter messy real-world data. Each of these can go undetected in testing because they only emerge under realistic conditions.

How do I know if a Power Automate action failed inside my Copilot Studio agent?

Silent action failures are a serious risk because the agent can continue the conversation and imply a task completed when it did not. You need explicit error handling and fallback logic in your flows so that failures surface to the user rather than being masked by a confident-sounding response.

When should I test my Copilot Studio agent against real production data?

You should test against realistic data before promotion to production, not after. System prompts written against clean test data can behave unpredictably when they encounter unexpected characters, mixed languages, or long strings that only appear in live environments. Incorporating a sample of real or representative data into your test suite is a necessary step before sign-off.

Category: Artificial Intelligence in Business

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

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

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.

Source: Build your server-side logic with AI: new Power Pages Agentic Code skills (Microsoft Power Platform Blog).

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

April 19, 2026
Why Power Automate Is Still Worth Learning in 2026

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published April 19, 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.

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

April 19, 2026
RPA Is Not the Right Tool for Every Repetitive Task

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

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

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

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.

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

April 17, 2026
Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat

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

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

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

April 17, 2026
Adding Copilot to Your Power App Is Not the Same as Making It Smarter
By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published April 16, 2026

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.

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
April 16, 2026
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.

April 15, 2026
Most Copilot Studio Agents Should Have Been Flows

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

Updated August 2026 rewritten to cover agent flows, multi-agent orchestration, and consumption billing, all of which changed the decision math since this post first went up.

I keep seeing this on LinkedIn and in community forums. Someone describes an internal use case, and the first five replies are all “have you tried Copilot Studio?” The tool has gotten good enough that it has become the reflexive answer to any question involving automation, conversation, or AI. That reflex is causing real problems, and it got worse over the past year, not better. Knowing when Copilot Studio is the wrong tool is as important as knowing how to build with it well.

When Copilot Studio Is the Wrong Tool for the Job

Most misuse I see falls into one of three situations. The use case is purely transactional. The interaction model is not conversational. Or the team wants a workflow, not an agent.

If someone needs to submit a form, approve a request, or trigger a process on a schedule, that is Power Automate territory. Putting a conversational interface in front of a single-action task does not make it better. It makes it slower, harder to test, and harder to maintain. Users do not want to type a sentence to do something they could do in two clicks.

The second situation is harder to spot. Some interactions look conversational but are not. A knowledge base search, a document lookup, a status check. These are point-in-time queries with no real back-and-forth. You could build them in Copilot Studio. You could also build them as a Power Apps canvas app with a simple search interface and ship it in a day with fewer moving parts and a much more predictable failure surface.

The Hype Got Louder, the Question Stayed the Same

Since I first wrote this post, Copilot Studio picked up autonomous agents, multi-agent orchestration, MCP tool connections, and agent flows. That is a genuinely bigger toolbox. It also means the “have you tried Copilot Studio?” reflex now covers even more ground, because the tool can technically do almost anything.

Notice what Microsoft did with agent flows, though. They put deterministic, workflow-style automation inside the agent product. That is a quiet admission of the exact point this post makes: a large share of what people were building as conversational agents never needed a conversation. It needed a sequence of steps that runs the same way every time.

The other change that matters is billing. With consumption-based messages, every generative answer and every agent action has a metered cost. A flow that runs a thousand times a day is a known quantity. An agent that reasons its way through a thousand sessions a day is a variable one. I ran into this internally on a triage agent where the message consumption was several times the initial estimate, purely because users chatted more than the design assumed. If your use case can be a flow, the flow is cheaper, and the cost is predictable before you ship.

The Agent Complexity Problem

There is also a complexity ceiling that teams hit faster than expected. Copilot Studio agents work well when the conversation scope is tight. One domain. A few topics. Defined intents. When someone tries to build a single agent that handles HR queries, IT requests, and finance approvals inside the same session, topic routing starts failing at the edges. I wrote about this in Your Copilot Studio Agent Passed Every Test and Still Failed in Production. When a user’s phrasing sits between two topics, the agent picks one confidently and gets it wrong.

Multi-agent orchestration was supposed to fix this, and it helps. You can now build narrow specialist agents and route between them instead of stuffing everything into one. But orchestration does not remove the routing problem. It moves it up a level. Now the orchestrator can hand off to the wrong specialist, and you are debugging a conversation across agent boundaries instead of across topics. It is a better architecture for genuinely complex domains. It is not a reason to make a simple use case complex.

Where the Wrong Choice Usually Starts

It usually starts with the framing of the requirement. Someone says “we want an agent” and that phrase triggers Copilot Studio before anyone has defined what the interaction actually needs to do. Two years ago the phrase was “we want a chatbot.” The word changed, the mistake did not. I have watched teams spend weeks building agent topics, writing instructions, and wiring up actions, when what the users actually wanted was better SharePoint search and a weekly digest email.

The honest question to ask before opening Copilot Studio is this: does this use case genuinely require back-and-forth conversation, or does it just need to surface information or move data? If the answer is the second one, there is almost always a simpler path.

This is not a knock on Copilot Studio. The tool is genuinely capable when it fits the problem. Multi-turn conversations, routing across complex intent patterns, integrating generative answers with structured actions, autonomous work over connected tools. Those are things it does well. But that capability comes with real operational cost. There is a topic structure to maintain, instructions that drift when production data introduces edge cases, and actions that can fail silently inside a topic and return a confident-sounding response for work that was never done.

What to Reach for Instead

Power Apps for anything with a fixed interaction model. Canvas apps are underrated for internal tooling. They give you a defined UI, predictable state, and a clear place to debug when something breaks.

Power Automate for anything triggered, scheduled, or event-driven. If there is no user in the loop having a conversation, there is no reason for a conversational agent to be involved. Keep in mind that even straightforward flows run into issues at scale, as Power Automate throttling limits will break your flow in production under real load if you have not accounted for them.

SharePoint or Dataverse with a search interface for knowledge retrieval. If users are looking something up, build a search experience, not a conversational one.

In enterprise environments, the governance overhead also matters. You are managing an agent that generates natural language responses. That quality needs to be reviewed, monitored, and occasionally corrected. People I talk to at other orgs consistently underestimate this cost until the first bad answer lands in front of a director. Add the consumption billing on top and the total cost of an agent is much higher than the demo suggests.

My working rule after a few years of building these things full time: reach for Copilot Studio when the conversation is the product. Reach for everything else when the conversation is decoration. If you disagree, or you have hit a case that breaks this rule, tell me about it. I collect these on LinkedIn and they regularly change how I think about this.

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

April 15, 2026
Low-Code Roundups Answer a Question Enterprises Never Ask

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

Updated August 2026 added the agent governance angle, updated the DLP and Managed Environments context, and sharpened the stakeholder response section now that AI agent roundups have joined the pile.

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

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

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

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

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

What Roundups Get Wrong About Power Platform at Scale

These lists treat features as equivalent when they are not. Power Automate supports HTTP calls, so does Zapier, check. Both have triggers and conditional logic, check and check.

What they do not cover is governance when you have hundreds of flows built by dozens of makers across multiple environments. Power Platform has environment-level DLP policies that control which connectors can touch which data. You can block a connector tenant-wide from the admin centre. Managed Environments let you enforce solution-aware deployments, sharing limits, and maker onboarding rules before anything goes near production. None of that shows up in a feature checklist. It is architecture you depend on when something breaks at 2am and you need to know exactly what touched what.

Connector governance also ties directly into Entra ID. Service principal authentication, conditional access, managed identities for flows calling Azure resources. These are not nice-to-haves. They are what your security team asks about before any automation touches HR or finance data. A comparison that skips this is not comparing the thing an enterprise is actually buying.

The Agent Layer Made This Worse, Not Better

This is the part I added in 2026, because the roundup problem has spread. The lists now rank agent builders too. Copilot Studio versus a dozen standalone agent platforms, scored on how fast you can ship a chatbot.

Same mistake, higher stakes. An agent is an automation with judgement. The governance question is not whether it can call a tool, it is whether you can see every action it took, restrict which knowledge sources it reads, and audit what it told whom. Copilot Studio inherits the tenant’s DLP, audit log, and Entra identity model. Agents built there show up in the same admin centre as everything else. A standalone agent platform gives you a shinier canvas and a second, separate governance problem.

If a flow leaking data was bad, an agent leaking data is worse, because the agent decides on its own what to fetch. The lists ranking these tools almost never mention it.

The Tenant Boundary Argument Nobody in These Lists Makes

Everything inside your Microsoft tenant shares an identity layer, a licensing model, an audit log, and a set of compliance controls. Power Platform lives inside that boundary by design. When a flow calls Dataverse, or a Copilot Studio agent hands off to an agent flow, or a Power App writes back to SharePoint, nothing crosses a boundary. It is all one governance envelope.

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

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

How to Respond When Someone Senior Sends You One of These Articles

This still happens, and more often now that agent roundups exist. Someone reads a list, sees another tool scored well on ease of use or pricing, and asks a fair question. Here is how I handle it, and it is roughly what I tell people I talk to at other orgs when they run into the same thing.

Do not get defensive about Power Platform. That reads as tribal and closes the conversation. Reframe instead. The roundup answers “which tool is easiest to try”. The enterprise question is “which tool can we govern, audit, and scale without adding a new identity boundary”. Say it in one sentence and most stakeholders get it immediately.

Then offer the honest caveat. There are cases where a third-party tool genuinely fits, usually at the edges, integrating with systems Microsoft connectors do not cover well. Name that possibility yourself. It shows you evaluated the option instead of dismissing it, and it makes the boundary argument land harder for everything that stays inside.

The comparison lists will keep coming. The frame is the thing worth defending, not the logo.

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

April 14, 2026
Your Copilot Studio Agent Passed Every Test and Still Failed in Production

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

I came across a post from Zapier Blog about AI agent evaluation, and it described something I keep seeing inside large organisations: an agent that looks perfect in a demo, gets signed off, goes live, and then immediately starts doing things nobody expected. Wrong tool calls. Conversation loops that never resolve. Outputs that look confident and are completely wrong. The post frames this well as a sandbox problem. But the fix it describes, better test coverage and smarter metrics, only gets you partway there. The deeper issue with Copilot Studio agent testing is not the quantity of your tests. It is what you are actually testing for.

Why Demo-Passing Agents Break in Real Workflows

When a team builds an agent in Copilot Studio, they test it against the happy path. A user asks a clean question. The agent triggers the right topic or action. The response looks good. Someone in the review meeting says it works great. The agent gets promoted to production.

The problem is that real users do not ask clean questions. They ask incomplete ones. They switch intent halfway through a conversation. They paste in text that includes formatting your prompt never anticipated. They use your agent for things it was never designed to do, because nothing in the interface tells them not to.

None of that shows up in a demo. It shows up three days after go-live when someone forwards you a conversation log that reads like a stress test you forgot to run.

The Three Failure Modes I Keep Seeing in Copilot Studio Agents

After building and reviewing a number of agents internally, the failures cluster into three patterns.

Topic misrouting at the edges. Your agent routes correctly when the user says exactly what you expected. But natural language is messy. When a user’s phrasing sits between two topics, the agent picks one confidently and gets it wrong. You only discover this when someone captures a failed session and traces it back. By then, a dozen other users have hit the same wall and just stopped using the agent.

Action failures that degrade silently. A Power Automate flow or a connector action fails in the background and the agent carries on as if nothing happened. No error surfaced. No fallback triggered. The user gets a response that implies the task completed. It did not. This is the agent equivalent of a flow that retries quietly and masks the problem until the load goes up. I wrote about that pattern in the context of Power Automate throttling limits breaking flows under real load. The same logic applies here: silent success is not success.

Prompt instruction drift under real data. Your system prompt was written against clean test data. Production data is not clean. It has unexpected characters, long strings, mixed languages, or values that push the model toward an interpretation you did not intend. The agent’s behaviour drifts. Not catastrophically. Just enough to become unreliable in ways that are hard to reproduce and harder to explain to stakeholders.

How to Build a Behavioral Test Suite Instead of an Output Checklist

Most teams build an output checklist. Did the agent return the right answer for these ten questions? That tells you almost nothing about production behaviour.

What you actually need is a behavioral test suite. The difference is this: output testing checks what the agent said. Behavioral testing checks how the agent handled the situation.

Here is how I approach it inside Copilot Studio before promoting anything to production.

Build adversarial input sets, not just representative ones. For every topic your agent handles, write three versions of the trigger: the clean version, an ambiguous version that could belong to two topics, and a broken version with incomplete or oddly formatted input. If the agent routes all three correctly, you have something worth shipping. If it fails on the ambiguous case, you have a routing gap that will hit real users constantly.

Test conversation state, not just single turns. Copilot Studio agents hold context across a conversation. Test what happens when a user changes their mind on turn three. Test what happens when they ask a follow-up that assumes context the agent should have retained but might not. Single-turn testing misses an entire class of failure that only appears in multi-turn sessions. This is also why agentic workflows require a fundamentally different design approach, not just an AI layer placed on top of existing processes.

Inject real data samples into action inputs. Pull a sample of actual data from your environment and run it through the actions your agent calls. Do not use synthetic test data if you can avoid it. Real data has edge cases your synthetic data will never cover. If your agent calls a flow that queries a SharePoint list, run the query against the actual list with actual entries, including the ones with blank fields and formatting you did not anticipate.

Define explicit fallback behaviour and test it deliberately. Every agent should have a defined behaviour for when it cannot complete a task. Most teams add a fallback topic and assume it works. Test it by constructing inputs that should trigger it. If the fallback does not fire, or fires on the wrong inputs, fix it before go-live. A graceful failure is far better than a confident wrong answer.

What to Monitor After Go-Live and When to Pull an Agent Back

Testing before launch is necessary but not sufficient. Agent behaviour shifts as the inputs it receives in production diverge from what you tested against. You need monitoring in place from day one.

Track escalation rate and abandon rate per topic. If a topic is seeing significantly higher escalations than others, that is a signal of routing or response quality problems, not user error. Track action failure rates separately from conversation outcomes. An agent can complete a conversation and still have failed to do the thing the user needed.

Set a threshold before launch. If escalation rate exceeds a number you agree on in advance, or if a specific action is failing more than a defined percentage of the time, you pull the agent back or disable the affected topic. The threshold is arbitrary. Having no threshold at all is not.

The agents I have seen hold up in production are not the ones with the most sophisticated prompts. They are the ones where someone spent real time on the failure cases before launch and built actual monitoring into the plan from the start.

If you are still signing off agents based on demo performance, you are not testing. You are hoping.

Frequently Asked Questions

Why does my Copilot Studio agent testing pass in demos but fail in production?

Most Copilot Studio agent testing is built around ideal user inputs and predictable conversation paths, which do not reflect how real users actually behave. In production, users ask incomplete questions, switch intent mid-conversation, and use the agent in unintended ways that no demo ever surfaces. Testing needs to go beyond the happy path to catch these edge cases before go-live.

What are the most common failure modes in Copilot Studio agents?

The three patterns that appear most often are topic misrouting when user phrasing falls between two intents, action failures that complete silently without triggering any error or fallback, and prompt instructions that break down when they encounter messy real-world data. Each of these can go undetected in testing because they only emerge under realistic conditions.

How do I know if a Power Automate action failed inside my Copilot Studio agent?

Silent action failures are a serious risk because the agent can continue the conversation and imply a task completed when it did not. You need explicit error handling and fallback logic in your flows so that failures surface to the user rather than being masked by a confident-sounding response.

When should I test my Copilot Studio agent against real production data?

You should test against realistic data before promotion to production, not after. System prompts written against clean test data can behave unpredictably when they encounter unexpected characters, mixed languages, or long strings that only appear in live environments. Incorporating a sample of real or representative data into your test suite is a necessary step before sign-off.

Source: AI agent evaluation: How to test + improve AI agents (Zapier Blog).

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

April 14, 2026

Category: Artificial Intelligence in Business

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

What These Agentic Code Skills Actually Do When You Run Them

The Specific Scenario Where I Would Use This First

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

Frequently Asked Questions

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

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

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

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

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

What Power Automate Actually Does That Nothing Else Replaces

What I Would Focus on Learning First

Where This Knowledge Starts Paying Off in More Advanced Work

Frequently Asked Questions

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

What is the difference between Copilot Studio and Power Automate?

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

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

When RPA Is the Wrong Solution From the Start

The Fragility Cost Is Not Theoretical

Process Quality Matters Here Too

The Decision Should Take Five Minutes

Frequently Asked Questions

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

Why does RPA break so often in production?

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

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

The chatbot framing is getting in the way

What makes Claude specifically interesting for orchestration logic

Where I would actually slot this into a Power Platform architecture

The honest constraints before you redesign anything

Frequently Asked Questions

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

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

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

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

What a Useful Agentic Workflow Actually Does

Where Teams Go Wrong Building Agentic Workflows

The Two Things That Make or Break an Agentic Workflow

What Agentic Workflows Are Actually Good For

The Test I Use

Frequently Asked Questions

What

What App Skills and Agent Integration Actually Do Under the Hood

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

What I Check Before Wiring Any Agent Into an Existing App

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

What Building Automations Teaches You About How Work Actually Flows

The Specific Process Failures That Surface When You Try to Automate

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

Why Fixing the Process First Does Not Mean Waiting to Build

What I Actually Do Now

When Copilot Studio Is the Wrong Tool for the Job

The Hype Got Louder, the Question Stayed the Same

The Agent Complexity Problem

Where the Wrong Choice Usually Starts

What to Reach for Instead

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

What Roundups Get Wrong About Power Platform at Scale

The Agent Layer Made This Worse, Not Better

The Tenant Boundary Argument Nobody in These Lists Makes

How to Respond When Someone Senior Sends You One of These Articles

Why Demo-Passing Agents Break in Real Workflows

The Three Failure Modes I Keep Seeing in Copilot Studio Agents

How to Build a Behavioral Test Suite Instead of an Output Checklist

What to Monitor After Go-Live and When to Pull an Agent Back

Frequently Asked Questions

Why does my Copilot Studio agent testing pass in demos but fail in production?

What are the most common failure modes in Copilot Studio agents?

How do I know if a Power Automate action failed inside my Copilot Studio agent?

When should I test my Copilot Studio agent against real production data?