Halilcan Soran

Tag: Power Platform

  • Power Pages Agentic Code Now Supports Server-Side Skills

    Power Pages Agentic Code Now Supports Server-Side Skills

    Power Pages agentic code server-side skills generating Liquid and Web API logic

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

    Microsoft just shipped three new skills for the Power Pages agentic code plugin that finally let GitHub Copilot and Claude Code CLI generate server-side logic, not just front-end markup. The announcement landed on the Power Platform blog and this is the gap-closer I have been waiting for. Power pages agentic code server-side generation is the part that was missing.

    If you have built anything non-trivial on Power Pages you know the pattern. The studio handles the front-end fine. The moment you need a Web API call, a table permission rule, or a Liquid template that actually does work, you are out of the visual layer and into code that the AI tools could not see properly.

    What it actually does

    The plugin now ships three new skills focused on the server-side surface of a Power Pages site. From the post and what I have read so far, these cover generating and wiring up Liquid templates with the right context, scaffolding Web API calls against your actual Dataverse tables, and producing the configuration around table permissions and site settings that normally requires you to know exactly which knob to turn.

    The important detail is grounding. The plugin pulls from your real site context: the tables you have, the columns on them, the page structure, the site settings already in place. So when GitHub Copilot or Claude Code CLI generate Liquid or a Web API snippet, it is generated against your actual environment, not a hypothetical portal.

    I wrote about this grounding problem before in an earlier post on Power Pages and AI. Generic LLM output for Liquid looks correct and breaks immediately on deploy because the model has no idea what your tables are called or what permissions are wired up. Environmental grounding is the entire game here.

    Why server-side AI generation is different leverage

    Front-end scaffolding from AI is useful but cheap. Anyone can prompt a model to spit out HTML and CSS for a form. The hard part of Power Pages was never the markup. It was the layer underneath: Liquid templates, Web API permissions, plugin logic, the settings that decide whether a record is visible to an authenticated contact or not.

    That layer is where sites break. That layer is where you used to bolt on a Power Automate flow because it felt easier than figuring out the right server-side pattern. And bolting on a flow for what should be a server-side query is exactly the kind of decision that creates a silo three months later when nobody remembers why the form posts to a flow instead of using the Web API directly. Understanding Power Automate error handling patterns helps when those flows do need to exist, but the goal should be keeping server-side work on the server side.

    Generating server-side logic with proper grounding cuts that path off. You stay inside the site. You use the layer that was already designed for it. The trade-off is real though: you now have AI-generated Liquid and permissions in a place where mistakes are harder to spot than a broken button. Server-side bugs do not show up as the dreaded broken image icon. They show up as a record being visible to the wrong user, which is a much worse failure mode.

    This is why I keep saying tool design for AI agents is an API design problem. The quality of the environmental signals fed to the model matters more than the model itself. Microsoft Learn for Power Pages is the reference I keep open when I am sanity-checking what these skills produce.

    What I would do with it this week

    I would pick a small internal-style site with two or three Dataverse tables, authenticated users, and one workflow that currently lives in a Power Automate flow it should not live in. Something where a list view filters by the logged-in contact, and a form writes back to a related table.

    Then I would have Claude Code CLI do three things. First, generate the Liquid for the filtered list using the new skill, against the real tables. Second, generate the Web API call for the form submission with the right permissions, instead of the Power Automate detour. Third, write a small piece of logic that should obviously fail without context, like referencing a column that does not exist, just to see how the grounding holds up.

    The point is not to ship anything. The point is to find where it breaks. In my experience, the only honest way to evaluate one of these releases is to push it until it produces something wrong, then look at why. If you are thinking about where this fits in a broader agentic architecture, most agentic workflows are just fancy if/then logic until the grounding is solid enough to trust the generated output in production.

    If the grounding is as good as the announcement suggests, this changes how I would start any new Power Pages build going forward.

    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

  • Microsoft Shipped Multi-Agent Orchestration in Copilot Studio and the Patterns Matter More Than the Feature

    Microsoft Shipped Multi-Agent Orchestration in Copilot Studio and the Patterns Matter More Than the Feature

    Multi-agent orchestration patterns in Copilot Studio diagram

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

    Microsoft shipped general availability of multi-agent orchestration in Copilot Studio this month, letting one agent call another agent as a skill, including agents built in Azure AI Foundry and external M365 Copilot agents. The announcement landed on the Copilot Studio docs and the blog feed last week. If you build agents inside Microsoft 365, this changes how you should think about agent design starting now.

    I have been testing it for a few days. The feature itself is straightforward. The interesting part is which multi-agent orchestration pattern you pick, because most teams will default to the wrong one and rebuild six months from now.

    What it actually does

    You can now register another agent as a connected agent inside Copilot Studio. The parent agent sees it as a tool. When the LLM decides the user request fits the connected agent’s described purpose, it hands off the conversation, gets a structured response back, and continues reasoning.

    Three things are worth knowing. The handoff is generative, meaning routing depends on the description you write for each connected agent, not on trigger phrases. The child agent runs with its own instructions, its own tools, and its own knowledge sources. And the parent agent receives the child’s output as context it can reason over, not as a final answer it must return verbatim.

    You can chain this. Parent calls child A, child A calls child B. You can also fan out, where the parent calls multiple children based on the request shape.

    Why it matters

    Single-agent designs hit a wall fast. I wrote about this in Most Agentic Workflows Are Just Fancy If/Then Logic in a Trench Coat. When one agent owns too many topics, routing fails at the edges, the system prompt balloons past 4000 tokens, and every change risks breaking three unrelated flows.

    Multi-agent orchestration lets you split by domain. One agent for HR queries, one for IT, one for finance, each with its own tight instructions and tool list. The parent becomes a router with personality. That sounds clean, and it can be, but only if you pick the right pattern.

    From what I have seen building and from what I hear from people at other organisations, three patterns keep showing up:

    Supervisor pattern. One parent agent owns the conversation, delegates to specialists, aggregates results. Best when the user does not need to know which agent is answering. Trade-off: the parent’s instructions become the bottleneck. If the parent picks the wrong child confidently, you get the same misrouting failure mode I described in my post on Copilot Studio agents passing tests and still failing in production, just one layer deeper and harder to debug.

    Sequential pipeline. Agent A produces output, agent B consumes it, agent C finalises. Best for structured workflows like draft, review, publish. Trade-off: latency stacks. Each hop adds seconds, and latency is the quiet killer of agentic workflows — budgeting round-trip time before you build matters more than most teams expect.

    Peer network. Agents call each other based on need, no fixed parent. Powerful, almost always premature. I have not seen a single internal use case where this beats a supervisor design once you account for debugging cost.

    The real win is not the multi-agent capability itself. It is the reduction in system prompt size per agent. When each agent has 400 tokens of focused instructions instead of 4000 tokens trying to cover everything, behavior gets predictable. Output testing gets meaningful. Drift gets easier to catch.

    What I would do with it this week

    Pick one existing Copilot Studio agent that has grown too many topics. Look at the system prompt. If it is over 2000 tokens or covers more than two distinct domains, it is a candidate.

    Split it. Create one child agent per domain. Move the relevant tools, knowledge sources, and instructions into the child. Write a clear description for each child, because that description is what the parent’s LLM uses to route. Vague descriptions kill routing accuracy faster than anything else. If you need to wire external capabilities into those child agents, building a custom connector for Copilot Studio is the practical path for connecting APIs that do not already have a prebuilt connector.

    Then test the edges. Phrasings that sit between two children. Requests that should hit two children sequentially. Requests that should fail cleanly when no child fits. The supervisor pattern looks great on the happy path. The behavior at the edges is what tells you whether the split was worth it.

    Multi-agent orchestration is not a silver bullet, it is a structural tool. Used right, it makes agents maintainable. Used wrong, it builds another silo with extra latency. The patterns matter more than the feature.

    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

  • How to Build a Custom Connector for Copilot Studio Step by Step

    How to Build a Custom Connector for Copilot Studio Step by Step

    Building a custom connector for Copilot Studio with OpenAPI definition and authentication settings

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

    The built-in connectors cover a lot, but the moment you need to talk to an internal REST API from a Copilot Studio agent, you need a custom connector. This walkthrough builds a working copilot studio custom connector end to end, from the OpenAPI definition to the agent calling it as a tool with structured output the LLM can actually reason about.

    The result: an agent that calls an internal API, gets back a typed JSON response, and uses it in the conversation without guessing.

    Step 1: Get your API contract straight before you open the portal

    Do not start in Power Apps. Start with the API spec. You need an OpenAPI 2.0 (Swagger) file or a clear list of endpoints, methods, query parameters, request bodies, and response schemas.

    If your API returns 200 OK with an empty body on success, fix that first. An agent needs structured output to evaluate what happened. I learned this the hard way building agentic flows: returning {"status":"done"} is not enough. Return the actual record, the actual ID, the actual changed fields.

    Make sure every response has a defined schema. type: object with named properties. No loose additionalProperties: true dumps. The agent reads the schema to decide how to use the result.

    Step 2: Create the custom connector in the Power Platform maker portal

    Go to make.powerautomate.com, pick the right environment (this matters, custom connectors are environment-scoped), then Data, Custom connectors, New custom connector, Import an OpenAPI file.

    Upload your Swagger file. Fill in:

    • Host: api.yourdomain.com (no https prefix)
    • Base URL: /v1 or whatever your API uses
    • Scheme: HTTPS only. Do not ship HTTP.

    If you do not have a Swagger file, use the blank template and define operations manually. It is slower but gives you full control over operation IDs and summaries, which the agent uses to pick the right tool.

    Step 3: Configure authentication properly

    For internal enterprise APIs, OAuth 2.0 with Microsoft Entra ID is the only option I would ship. API key auth works for prototypes and falls apart the moment you need per-user identity in the agent. The same principle applies when thinking about Power Platform governance that does not kill adoption — authentication decisions made at the connector level affect every maker and every environment downstream.

    In the Security tab, pick OAuth 2.0, Identity Provider Azure Active Directory, and fill in:

    • Client ID: from your app registration
    • Client secret: from the same registration
    • Resource URL: the App ID URI of the API, for example api://your-api-app-id
    • Scope: the scope you exposed on the API app registration, e.g. access_as_user

    Save, then copy the Redirect URL Power Platform generates and add it to your Entra app registration’s redirect URIs. Skip this and you will get AADSTS50011 on every connection attempt.

    Step 4: Define operations with names the LLM can understand

    This is where most connectors fail as agent tools. The operation summary and description are not metadata. They are the prompt the LLM uses to pick the tool.

    Bad: GetData. Good: Get order details by order ID.

    For each operation set:

    • Summary: what the operation does, in plain English
    • Description: when to use it, what it returns
    • Operation ID: camelCase, descriptive, like getOrderById
    • Parameter descriptions: every parameter, including required vs optional

    Test each operation in the Test tab before moving on. If it does not return clean JSON here, it will not work in the agent.

    Step 5: Add the connector to a Copilot Studio agent as a tool

    Open your agent in Copilot Studio. Go to Tools, Add a tool, then pick Connector and find your custom connector. Microsoft’s docs on connector tools in Copilot Studio cover the UI changes if anything looks different in your tenant. If you are still getting oriented with the platform itself, If You Are Starting Copilot Studio in 2026 Skip the Chatbot Tutorials is worth reading before you wire up your first tool.

    For each operation you want to expose:

    • Review the auto-generated tool description. Rewrite it if it is vague.
    • Mark inputs as Dynamically fill with AI for parameters the LLM should infer from conversation, or Custom value for static config.
    • Set the connection. For testing, use your own. For production, configure end-user authentication so each user authenticates with their own identity.

    Step 6: Test it end to end with realistic input

    In the Test pane, do not type the obvious phrasing. Type how a real user would ask. Watch the activity map. You want to see the tool getting picked, the parameters extracted correctly, the response coming back as structured JSON, and the agent using specific values from that JSON in its reply.

    If the agent paraphrases instead of citing values, your response schema is too loose or the tool description is misleading. Tighten both.

    The final state and one common pitfall

    You now have a custom connector calling an authenticated internal API, registered as a tool the agent can invoke based on conversation context, returning structured data the LLM uses in its response.

    The pitfall to watch for: connection caching across environments. A connector that works in your dev environment will not auto-promote. You need to export the solution, import it into the next environment, and recreate the connection reference there. Skip that and your ALM pipeline will fail in ways that look like auth bugs but are really environment scoping. If your setup involves agents talking to external systems across multiple environments, the same scoping problems come up in Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl.

    Frequently Asked Questions

    How do I create a custom connector in Copilot Studio?

    To build a Copilot Studio custom connector, start by preparing an OpenAPI 2.0 (Swagger) file that defines your API endpoints, parameters, and response schemas. Then go to make.powerautomate.com, navigate to Data, Custom Connectors, and import your Swagger file. From there you configure authentication, define your operations, and connect the connector to your Copilot Studio agent as a tool.

    What is the best authentication method for a custom connector in Power Platform?

    OAuth 2.0 with Microsoft Entra ID is the recommended approach for enterprise APIs, as API key authentication does not support per-user identity. Authentication choices made at the connector level affect every maker and environment that uses it downstream, so it is worth getting right from the start.

    Why does my Copilot Studio agent not understand the API response correctly?

    If your API returns a vague or empty response body, the agent has nothing structured to reason about. Every response should include a defined schema with named properties so the agent can interpret the result and decide how to use it in the conversation.

    When should I build a custom connector instead of using a built-in one?

    You need a custom connector when your Copilot Studio agent needs to call an internal or proprietary REST API that is not covered by the existing built-in connectors. If your use case involves company-specific data or internal services, a custom connector is the right path.

    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

  • Power Automate Error Handling Patterns That Actually Work

    Power Automate Error Handling Patterns That Actually Work

    Power Automate error handling patterns with scopes and run after configuration

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

    Most Power Automate error handling I see in the wild is one Try scope, one Catch scope, and a Teams message that says Flow failed. That is not error handling. That is a notification with extra steps.

    Real Power Automate error handling patterns answer three questions. What failed. Why it failed. What happens to the work that was already in flight when it failed. If your flow does not answer all three, you are going to find out about problems from an angry colleague, not from your monitoring.

    I have rebuilt enough flows after silent failures to have strong opinions on this. Here is what I actually use.

    The Try Catch Finally pattern is the floor, not the ceiling

    Three scopes. Try runs your logic. Catch is configured with Run After set to has failed, is skipped, and has timed out. Finally runs after both, regardless of outcome. This is documented well in the Microsoft Learn Power Automate docs and most builders get this far.

    The problem is what people put inside Catch. Usually a single Post Message action with @{workflow()?['run']?['name']} and a generic failure string. That tells you the flow failed. You already knew that. It does not tell you which action failed inside the Try, what the actual error message was, or what input caused it.

    The fix is using result('Try') inside Catch and filtering for items where status is not Succeeded. That gives you the specific action name, the status code, and the error body. Now your alert is useful.

    Differentiate transient from terminal errors

    This is the pattern most flows skip and it is the one that matters most in production. A 429 from a connector is not the same problem as a 400 from bad input. One needs a retry with backoff. The other needs a human.

    Inside Catch, parse the error and branch. Status codes 408, 429, 500, 502, 503, 504 are transient. Retry them, ideally with a Do Until that has a delay and a max iteration count. Status codes 400, 401, 403, 404 are terminal. Do not retry. Log them and move on or escalate.

    Power Automate’s built-in retry policy on individual actions covers some of this, but it does not let you do anything intelligent with the failure. It just retries with exponential backoff and then gives up. For anything that touches an external system with rate limits, I wrote about how this connects to throttling limits and why default retry behaviour can mask problems until volume increases.

    Compensating actions for partial failures

    This is the one almost nobody does. If your flow creates a SharePoint item, then sends an email, then updates a Dataverse record, and step three fails, what happens to steps one and two? Nothing, by default. You have a SharePoint item that should not exist and an email that should not have been sent.

    The pattern is simple. Inside Catch, run compensating actions for whatever Try already completed. Delete the SharePoint item. Send a correction email. Mark the Dataverse record as Failed rather than leaving it half-updated. You do this by checking result('Try') for which actions actually succeeded before the failure, then reversing only those. If you are using SharePoint lists as your backend, as I covered in SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps, the compensating delete is straightforward because the list item ID is always available in scope.

    It is more code. It is also the difference between a flow that fails cleanly and a flow that leaves your data in a state nobody can reason about three weeks later.

    Centralise error logging

    Stop writing custom logging logic in every flow. Build one child flow that takes the run ID, the flow name, the failed action, the error body, and the input payload, and writes it to a single Dataverse table or SharePoint list. Every flow calls that child flow from its Catch scope.

    Now you have one place to look when things break. You can build a Power BI report on it. You can spot patterns across flows. You can see that 80 percent of your failures are coming from one connector and actually fix the root cause instead of patching individual flows.

    The notification trap

    If every failure sends a Teams message, people stop reading them within two weeks. I have seen this play out on multiple internal builds. Tier your alerts. Transient errors that self-recover do not need a notification. Terminal errors that need human input do. Compensating actions that ran successfully need a log entry, not a ping.

    The goal is that when a notification arrives, the person receiving it actually opens it. Anything else is noise. This connects to a broader problem I have written about in Power Platform Governance That Does Not Kill Adoption, where poorly designed alerting policies erode trust in automation the same way overly restrictive DLP policies erode maker trust in the platform.

    The pattern that ties it together

    Try Catch Finally for structure. Result filtering for specificity. Transient versus terminal branching for intelligence. Compensating actions for data integrity. Centralised logging for visibility. Tiered notifications for sanity.

    None of this is exotic. All of it is skipped because the happy path works in testing and the edge cases only show up at volume. Build the error handling first. The flow will be slower to ship and faster to trust. And if you are still deciding whether Power Automate is worth investing this depth of effort into, Why Power Automate Is Still Worth Learning in 2026 covers exactly that question.

    Frequently Asked Questions

    What are the best power automate error handling patterns to use in production flows?

    Effective power automate error handling patterns go beyond a basic Try and Catch scope. You should capture specific action-level failures using result(‘Try’), differentiate between transient and terminal errors, and include compensating actions to undo partial work when a flow fails midway.

    How do I find out which action failed inside a Power Automate Try scope?

    Use the result(‘Try’) expression inside your Catch scope and filter for items where the status is not Succeeded. This returns the specific action name, status code, and error body, giving you meaningful diagnostic information instead of a generic failure message.

    When should I retry a failed action in Power Automate versus escalate to a human?

    Retry transient errors such as 408, 429, 500, and 503 using a Do Until loop with a delay and a maximum iteration count. Terminal errors like 400, 401, 403, and 404 indicate a problem with the request itself, so retrying will not help and the failure should be logged or escalated instead.

    Why does Power Automate’s built-in retry policy not work well for rate-limited connectors?

    The default retry policy applies exponential backoff and then stops, but it does not let you inspect or act on the failure in a meaningful way. At low volumes this can go unnoticed, but as traffic increases the lack of intelligent handling can cause widespread failures that are difficult to diagnose.

    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

  • Microsoft Discovery Is the First Real Glimpse of Domain-Specific Agent Platforms

    Microsoft Discovery Is the First Real Glimpse of Domain-Specific Agent Platforms

    Microsoft Discovery agentic RD platform sitting above Copilot Studio in the enterprise agent stack

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

    I came across the Azure Blog post about Microsoft Discovery expanding its preview, and it crystallised something I have been chewing on for months. Most enterprise AI conversation right now is stuck on horizontal agents. Generic copilots doing generic things across generic data. Microsoft Discovery agentic RD goes the other direction, and that direction is where the interesting architectural decisions are about to happen.

    What Microsoft Discovery Actually Is If You Skip the Marketing

    Strip the announcement language away and Discovery is a vertical agent platform shaped specifically for research and development workflows. It is not a chatbot. It is not Copilot Studio with a science skin. It is a purpose-built layer with domain primitives baked in: scientific data structures, simulation orchestration, multi-agent coordination tuned for R&D problems instead of generic enterprise tasks.

    The important word is shape. A horizontal agent platform gives you a blank canvas and a set of generic tools. A domain-shaped platform gives you a canvas where the grid lines already match the work. You give up flexibility. You gain a tenth of the build time when the shape fits.

    Why Domain-Shaped Agent Platforms Beat Generic Copilots for R&D Workflows

    I have written before about how most agentic workflows are just fancy if/then logic in a trench coat. The reason is almost always the same. Teams use a general-purpose tool to model a domain it does not understand, then spend weeks bolting domain logic on top through prompts and tool definitions.

    R&D is the perfect example. A real research workflow involves hypothesis tracking, simulation runs, candidate scoring, lineage of why a decision was made three steps ago. None of that is native to a generic Copilot Studio agent. You can build it. I have seen people try. It ends up as a fragile stack of topics, variables, and Power Automate flows pretending to be a state machine.

    A domain-shaped platform encodes those primitives directly. The agent does not need a 4000-token system prompt explaining what a candidate molecule is, because the platform already knows. That is the productivity unlock, and it is also why I think we are about to see a lot more of these.

    How This Changes the Build vs Buy Decision for Power Platform Teams

    Here is the part Power Platform people should pay attention to. The skill that matters going forward is not how well you can build in Power Automate or Copilot Studio. It is picking the right altitude for the automation in front of you.

    I keep seeing teams default to building everything in Copilot Studio because that is the tool they know. Someone wants a research assistant. Someone wants a contract review agent. Someone wants a finance close helper. All of it gets crammed into Copilot Studio topics and custom connectors, and six months later the build is brittle, slow, and three people deep in technical debt. If you are just getting started, getting started with Copilot Studio in 2026 means skipping the chatbot tutorials entirely and learning to think in terms of orchestration first.

    The decision tree is going to look more like this:

    • Is there a domain-shaped platform that already models this work? Use it. Customise on top.
    • Is the workflow generic but cross-system? Copilot Studio agent with deterministic Power Automate flows underneath.
    • Is the workflow narrow, predictable, high volume? Raw Power Automate. No agent. No reasoning layer. Just a flow.
    • Is the workflow heavy on judgment with messy unstructured inputs? Reasoning model in the orchestration layer, not the response layer. I covered this in my post on Claude as orchestration brain.

    Picking the wrong altitude is the most expensive mistake I see. Discovery is interesting precisely because it adds a new altitude that did not exist in the Microsoft stack before. R&D teams who would have been forced into Copilot Studio now have a layer that fits their work natively.

    What I Would Watch For Next in the Microsoft Agent Stack

    Discovery is the canary. R&D is just the first vertical because Microsoft has obvious customers there and the workflows are well-understood. The pattern will repeat. I would expect domain-shaped agent layers for clinical workflows, manufacturing operations, financial close, regulatory review. Each one will sit above the general-purpose Copilot stack and offer the same trade: less flexibility, much faster time to a working system.

    The thing I am watching is interoperability. Can a domain platform like Discovery call out to a Copilot Studio agent for a side task? Can a Power Automate flow trigger a Discovery workflow? If yes, the stack becomes composable and the architectural decisions get genuinely interesting. If no, we end up with another round of silos with their own latency problems and integration debt.

    For now, the practical move is to stop treating Copilot Studio as the universal hammer. In my experience, the teams who consistently ship working automations are the ones who match the tool to the shape of the work. Discovery just made that decision a little more interesting.

    Frequently Asked Questions

    What is Microsoft Discovery and how does it differ from Copilot Studio?

    Microsoft Discovery is a purpose-built agent platform designed specifically for research and development workflows, not a general-purpose copilot tool. Unlike Copilot Studio, it comes with domain-specific primitives like scientific data structures and simulation orchestration built in, so teams spend far less time engineering workarounds for R&D-specific tasks.

    How does Microsoft Discovery agentic RD improve research and development workflows?

    Because the platform already understands R&D concepts like hypothesis tracking, candidate scoring, and simulation runs, agents do not need lengthy prompts or custom-built logic to handle them. This reduces build time significantly compared to trying to model the same workflows on a generic agent platform.

    When should I choose a domain-specific agent platform over a generic one like Copilot Studio?

    A domain-specific platform makes sense when your workflows map closely to the vertical it was designed for, since the built-in primitives cut build time and reduce fragility. If your use case is too broad or does not fit the platform shape, a general-purpose tool with custom configuration will give you more flexibility.

    Why do generic agentic workflows often fail for complex enterprise use cases?

    General-purpose platforms require teams to manually encode domain logic through prompts, tool definitions, and automation flows, which produces brittle systems that are hard to maintain. When the platform has no native understanding of the domain, complexity accumulates quickly and the resulting agent is difficult to scale or debug.

    Source: Microsoft Discovery: Advancing agentic R&D at scale (Azure 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

  • Power Platform Governance That Does Not Kill Adoption

    Power Platform Governance That Does Not Kill Adoption

    Power Platform governance that does not kill adoption in an enterprise environment

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

    I keep seeing the same pattern on LinkedIn and in conversations with people at other organisations. Power Platform governance gets handed to a security team, they lock everything down, and six months later nobody is building anything. Then someone writes a post about low adoption and blames the makers. It is not the makers. It is the governance design.

    Good Power Platform governance is not about stopping people. It is about making the safe path the easy path. If your governance model forces a citizen dev to file three tickets and wait two weeks to use a SharePoint connector, you do not have governance. You have a queue.

    The two failure modes of Power Platform governance

    Every governance setup I have seen fails in one of two ways.

    The first is the lockdown. Default environment is disabled for everyone. Every connector is in the Blocked DLP group unless explicitly approved. New environments require a business case signed by three people. Makers give up and go back to Excel macros. Shadow IT grows in Teams and OneDrive where nobody is watching.

    The second is the free-for-all. Everyone builds in the default environment. No DLP. No naming conventions. Flows owned by people who left two years ago still run in production because nobody knows what they do or who to ask. The CoE Kit is installed but nobody looks at the dashboards.

    Both end in the same place. Leadership decides Power Platform does not work for the enterprise. The real problem was never the platform.

    What actually works

    The teams I talk to who have this working treat governance as a product with makers as the users. That framing changes everything.

    They have a managed maker environment that anyone in the org can request access to in under an hour. Standard connectors are in the Business group. Premium and risky connectors need justification but the path is documented. People know where to go.

    They have a promotion path from maker environment to a shared Dev, then UAT, then Prod. Each environment has different DLP settings and the differences are written down. This is the part most teams miss. I wrote about this before in the context of Power Platform agents and GitHub integration, where a connector sitting in Business in Dev and Blocked in Prod silently kills an agent at go-live. Same pattern applies to any flow or app that crosses environments.

    They have an ownership policy that actually runs. When someone leaves, their flows and apps get reassigned within a defined window, not forgotten. The Power Platform PowerShell modules handle most of this if you script it. The CoE Kit is fine for inventory but I have stopped relying on it as the source of truth for ownership because the lag is too long.

    DLP policies that do not punish makers

    Most DLP policies I see are written by someone who has never built a flow. They block the HTTP connector by default and then wonder why nobody integrates with anything. Or they put SharePoint and Outlook in different data groups and break every approval flow in the tenant.

    The approach that works is starting from what makers actually need and working backwards. Look at what the top 50 flows in your tenant use. Build your Business data group around that. Put the genuinely risky stuff like custom connectors to unknown endpoints in Blocked. Review quarterly, not yearly.

    And write the policy down in plain language somewhere makers can find it. Not a SharePoint page buried in the IT site. Pin it in the Teams channel where makers ask questions.

    The CoE Kit is not a governance strategy

    I see this a lot. A team installs the CoE Kit, enables a few flows, and calls it done. The CoE Kit is a starting point. It is inventory and some reporting. It is not a governance strategy on its own.

    The manual updates every few months genuinely do break things. The premium license requirement for some of the governance features is a real cost. The handoff complexity when the person who installed it leaves is a known problem. None of this is a secret.

    What I have seen work is using the CoE Kit for what it is good at, which is discovery, and building lightweight custom tooling for the parts that matter to your org. Inactivity policies. Ownership reassignment on leaver events. Environment request intake. None of this needs to be fancy. A few flows and a SharePoint list go a long way, which ties back to a point I have made before about SharePoint being the right backend for most Power Platform needs.

    Governance is a product

    The shift that changed how I think about this is treating governance as a product with makers as the customer. If makers avoid your governance model, it is broken. If they route around it, it is broken. If they ask for exceptions constantly, it is broken.

    The safe path has to be the easy path. Otherwise adoption dies and you spend the next year explaining to leadership why the platform did not deliver. If you are still building out the foundation, understanding why Power Automate is still worth learning in 2026 is a good place to start before layering governance on top of a platform your team is not yet fluent in.

    Frequently Asked Questions

    What is Power Platform governance and why does it matter?

    Power Platform governance is the set of policies, environments, and controls that shape how people build and share apps, flows, and agents in your organisation. When designed well, it protects the business without slowing down the people trying to do useful work. When designed poorly, it either locks everything down or lets chaos grow unchecked.

    How do I set up Power Platform governance without killing adoption?

    Treat governance as a product where makers are the users, not a security checklist applied on top of them. Give people a managed environment they can access quickly, document the DLP policies clearly, and make the approved path easier than any workaround. If the process to get started takes weeks, people will find another way.

    Why does my Power Platform app break when it moves from Dev to Production?

    This usually happens because DLP connector policies differ between environments and those differences are not documented anywhere. A connector allowed in your Dev environment may be blocked in Production, which silently breaks apps or flows at go-live. Writing down the DLP differences for each environment and testing against them before promotion prevents this.

    When should I reassign Power Platform flows and apps after someone leaves the organisation?

    Reassignment should happen within a defined window as soon as someone leaves, not reactively when something breaks. Flows and apps owned by former employees can keep running in production for years with no clear owner, which creates a serious operational and security risk. Power Platform PowerShell modules can automate much of this process.

    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

  • Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl

    Power Platform Agents Talking to GitHub Sounds Simple Until You Hit Enterprise Environment Sprawl

    Power Platform agent GitHub integration enterprise environment mapping diagram

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

    I keep seeing the same demo on LinkedIn. Someone wires a Power Platform agent to GitHub in ten minutes, the agent answers questions about a repo, everyone claps. Then a team at a real enterprise tries to copy the pattern and stalls for three weeks. The problem is never the connector. The problem is power platform agent github integration enterprise reality, where you have twelve environments, three GitHub orgs, DLP policies that differ per environment, and a security team that wants tokens rotated quarterly.

    The connector works. The environment strategy around it does not.

    Why the GitHub Connector Demo Lies to You

    In a demo, one person builds in their default environment, authenticates with their own GitHub account, and points the agent at a public or personal repo. Every layer of that setup is the easy path.

    Personal auth hides the service account problem. Default environment hides the DLP problem. A single repo hides the org sprawl problem. Running it locally hides the fact that the Prod environment sits in a different security posture entirely.

    I have watched teams ship an agent to UAT, watch it work, promote it to Prod, and then hit a wall where the connection simply cannot see the repo. No error message that is useful. Just empty knowledge and a confident agent saying it could not find the information. Same failure mode I wrote about in agent testing versus production behavior. The agent answers. The answer is empty. Nobody notices for a week.

    The Environment Sprawl Problem Nobody Scopes For

    Large enterprises do not have one Power Platform environment. They have Dev, multiple UAT environments per business unit, a shared services environment, regional Prod environments, a sandbox for citizen devs, and a couple of orphaned ones nobody wants to delete. Each one has its own DLP policy group at the tenant level.

    GitHub is not one thing either. Most large orgs I hear about run at least two GitHub organisations. Sometimes an enterprise account with several orgs under it. One for platform code, one for product code, maybe one for security-sensitive work behind SSO with stricter SAML enforcement.

    Now ask the real question. Which Power Platform environment is allowed to talk to which GitHub org, with which connector classification, using which identity? Most teams have never drawn this map. They build in Dev, it works, and they assume Prod behaves the same. It does not.

    The GitHub connector can sit in the Business data group in one environment and the Blocked group in another. The agent that passed UAT will not even load the connection in Prod because the policy blocks it. You find out at go-live.

    How I Would Map Power Platform Environments to GitHub Orgs and Repos

    Start with the principle that environment design is the hard part, not the connector. Then draw the map before you build anything.

    Dev Power Platform environment talks to a Dev GitHub org, or a dedicated sandbox org, with a scoped token and loose DLP. UAT talks to the same repos as Prod but through a read-only identity, so you are testing against real structure without write risk. Prod talks to Prod GitHub orgs through a managed service identity, with the connector in the Business data group and DLP exceptions documented.

    The knowledge source in the agent has to point at a repo that the target environment’s connection can actually see. This is where most builds break. The agent was built in Dev pointing at a repo in the Dev org. In Prod, that repo does not exist, and the Prod connection has no permission on the Prod equivalent. The fix is not technical. It is an environment variable pattern where the repo reference is parameterised per environment, and solution deployment swaps the value.

    The Microsoft Learn docs on environment strategy cover the platform side. They do not cover the mapping to external orgs. That part is on you.

    Service Accounts Tokens and the Stuff That Actually Breaks in Prod

    Personal Access Tokens are how every demo works and how no enterprise should run anything. The person who created the PAT leaves the company, the token is revoked, the agent goes dark. I have seen this happen. Twice.

    GitHub Apps are the right answer for Prod. Fine-grained permissions, installable per org, rotate credentials without losing the identity. The connector supports GitHub App auth. Use it. The trade-off is setup time. You have to get the security team to approve the app installation on the target org, which takes weeks in a large enterprise. Plan for that before you commit to a go-live date.

    Service account seats are the other thing that breaks quietly. The identity your Prod connection uses needs a seat on the target repo. In a GitHub Enterprise plan with seat limits, this is a budget conversation, not a technical one. I have seen agent deployments stall because nobody wanted to pay for an extra seat.

    Token rotation policy is the last piece. If your security team rotates every ninety days, build the rotation into your deployment pipeline, not into a calendar reminder. Otherwise the agent fails silently on day ninety-one and the confident-but-empty response problem shows up again. And if those silent failures start compounding across chained steps, you are looking at the kind of agentic workflow latency problem that is easy to miss until it is already affecting users.

    The connector is not the hard part. It never was. The teams that succeed stop treating integration as a connector problem and start treating it as an environment design problem. If you are still early in this process, getting started with Copilot Studio in 2026 means thinking through environment strategy from day one, not after your first failed Prod deployment. Draw the map first. Build second.

    Frequently Asked Questions

    How do I set up a Power Platform agent GitHub integration in an enterprise environment?

    Start by mapping which Power Platform environments need to connect to which GitHub organisations, and what DLP policies apply to each. You cannot assume a connection that works in Dev or UAT will behave the same way in Production, since connector classifications can differ across environments. Sorting out service account credentials and token rotation policies before you build will save significant rework later.

    Why does my Power Platform agent work in UAT but fail in Production when connecting to GitHub?

    The most common cause is a difference in DLP policies between environments. The GitHub connector may be classified as allowed in your UAT environment but blocked or restricted in Production, which stops the connection from loading at all. The agent will often still respond but return empty results, making the failure easy to miss until users report it.

    What is environment sprawl and why does it matter for Power Platform agent deployments?

    Environment sprawl refers to the accumulation of multiple Power Platform environments across an organisation, each with its own DLP rules, security posture, and connector permissions. It matters for agent deployments because a GitHub connection that is permitted in one environment may be completely blocked in another, and most teams do not map these differences before they start building.

    When should I use a service account instead of personal authentication for a GitHub connector in Power Platform?

    Any time the agent is intended for a team or production use case, a service account is the right choice over personal authentication. Personal credentials tie the connection to an individual user, which creates access and continuity risks when that person changes roles or leaves the organisation. A shared service account also makes token rotation and permission auditing much easier to manage.

    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

  • 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

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

    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.

    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

  • 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

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

    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.

    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

  • 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

    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