Pattern for governing Copilot Studio agents before they reach production
I keep seeing the same gap across Copilot Studio deployments: agents get built and shared before anyone has answered three basic governance questions. Before I call an agent production-ready, I check: -> Who's the sponsor? Not just who built it, who's accountable for it existing. -> What's it grounded on, and who can actually read that data? A knowledge source that's technically "in scope" isn't the same as verified content people should be answering from. -> Is there an audit trail for what the agent said and to whom, if someone asks later? None of this shows up in a demo. It only shows up a few months in, when the agent's still running and nobody remembers why. I wrote a longer breakdown of this governance model, including how Microsoft Agent 365 fits into it, here: https://uhm6mk828ymm69crw0jj8.subtlesoundimmersion.net/blog/microsoft-agent-365-licensing-what-you-actually-buy/ Curious what pattern others are using here, especially for the sponsor/ownership question, since that's the one I see skipped most.
You don't have access to talk to this bot, contact the owner. copilot studio
I created a copilot studio agent and then embedded it inside a code app. It works fine but i am facing the below error. You don't have access to talk to this bot, contact the owner. copilot studio I have provided Microsoft based authentication and am an owner so will have access to the bot. Yet facing the above issue. Is there something i am missing
Agent Credit Limits and Alerts - Copilot Studio
Hi everyone, We're evaluating the use of Agent Credit Limits and alert notifications in the Power Platform Admin Center as a way to control unexpected Copilot Credit consumption. Recently, we had an agent consume 668k Copilot Credits in just 3 days, which raised concerns about how quickly usage can grow before administrators become aware of it. My questions are: How frequently is Copilot Credit consumption evaluated against an agent's credit limit? Are alert notifications generated in near real-time, or are they dependent on the same reporting pipeline used by the consumption reports? If an agent reaches its configured credit limit, is it automatically turned off or blocked from further consumption? Given that consumption reports often appear to refresh hours later (or even the next day), can alerts also be delayed? If there is a reporting delay, is there a risk that an agent could significantly exceed the intended limit before administrators receive a notification? What is the recommended approach for preventing large unexpected consumption spikes in production? Has anyone successfully implemented a governance model that provides more immediate protection against runaway usage, or are the current credit limits and alerts primarily intended for retrospective monitoring? Thanks in advance for any guidance.Introducing the customer conversation harness in Microsoft Copilot Studio
By Omar Aftab, Vice President, Conversational AI The way customers interact with brands is fundamentally changing. More and more interactions are driven by conversational AI, and customers increasingly expect every interaction to be deeply personalized and contextual. With millions of people interacting with sophisticated AI systems every day, consumers are no longer willing to put up with legacy IVRs, restrictive menus, and loss of context. Engaging with customers has been central to Microsoft Copilot Studio from the very start. Copilot Studio customers have created thousands of agents that engage with their customers, whether those customers are chatting on a website, speaking with a voice agent on the phone, or using an AI agent embedded in an app or kiosk. Today we’re announcing the public preview of our new customer conversation harness in Copilot Studio. This is a purpose-built harness and builder specifically designed to create powerful conversational agents for customer engagement. It supports the full arc of a customer interaction in a modern world: connecting to customers across channels, understanding what they need, drawing on the right knowledge and tools, interacting with human representatives as needed, and providing a swift resolution – whether the customer is speaking or typing. To enable this, the harness introduces a set of core new conversational capabilities. These range from teams of agents that work together, more seamless interactions between generative skills and deterministic topics, powerful omnichannel conversations across chat and voice, to better human-agent interactions. The harness also enables integration with third-party contact centers through our new Microsoft Contact Center Intelligence product that we also announced today. Build intelligent conversational agents that work together At the center of the new harness is the new conversational agent builder. Makers can now build state-of-the-art experiences for voice and chat within a single agent. Every agent is omnichannel out of the box and has the skills you’d expect any versatile customer-facing representative to have. They speak conversationally. They understand multiple languages. They are channel-aware. You can move between digital and voice channels without losing context, and the agents maintain memory across them. Connect a team of specialized agents to business knowledge and tools The customer conversation harness makes it easy to orchestrate multiple agents to work together as a team of specialists. Each sub-agent can have its own knowledge and its own tools to hand its own specialized tasks. At GA, each agent will also be able use its own model. This means makers can choose which model is best suited to the kinds of jobs and intents each specialist agent handles. Some tasks call for deep reasoning, while others benefit from models optimized for cost and latency. The harness is designed to orchestrate and combine these agents seamlessly into one customer engagement system. What's more: Microsoft Foundry extensibility is built in. You can create a custom agent with code in Foundry and add it to the team of agents with just a few clicks. The harness handles the complexity and does the heavy lifting, allowing you to build on your existing assets or more easily leverage pro-code capabilities. Finally, Microsoft IQ, which helps ground AI experiences in your organization's work context and business data, is also backed into the harness and available to each agent. With Work IQ, agents can draw on information from the Microsoft 365 apps your team uses every day. For example, an agent helping resolve a billing dispute could reference a refund policy stored in SharePoint and also reference an exception that was agreed to in a Teams thread. The agent accesses this information with its own identity, respecting existing enterprise data access and security policies. Agents can also connect to Foundry IQ for large-scale knowledge sources, such as product manuals, warranty terms, and documents indexed in Azure AI Search; Fabric IQ for reasoning over business data; and more. Combine generative skills with topics Each agent in the team handles multiple jobs - whether it's recommending a credit card, looking up a balance, or taking a payment. And just like when giving a task to an employee, you can provide general instructions for some tasks, and provide specific turn-by-turn directions for others. In the new harness, each agent skill can either be fully generative - you simply provide a prompt and let the model use its own judgment (e.g. “Go and gather the credit card information from the user”) - or fully deterministic, using a topic (commonly used, for example, in IVRs or voice trees where exact, step-by-step instructions are desired). This flexibility is key for large customer engagement systems and has been a recurring customer ask. In the past, an agent could do one or the other. Now, each agent in your team can seamlessly handle a mix of both, depending on the job to be done. Deliver natural experiences across voice and chat Because the harness is natively omnichannel, voice is a first-class experience for both makers and customers. You can choose among speech models and configure rich voice capabilities. These include voice fonts for more natural and customized interactions, speech instructions to guide the agent’s tone and speaking style, DTMF behavior, speech sensitivity settings, and more. When you're ready to publish, you can even acquire phone numbers and deploy your agent to them, making the agent accessible to customers over the phone. And you can test and evaluate all of this right within the experience. Make customer verification easier with voice biometrics Authentication can be one of the most frustrating parts of a customer service call. Traditional verification methods, from security questions to one-time passcodes, can add time and friction before customers can even explain why they're calling. Verifying a customer's identity is essential, but it shouldn't get in the way of a great service experience. The new harness, together with Contact Center Intelligence, supports enterprise grade state-of-the-art voice biometrics that help authenticate customers in real time. Rather than ask a rigid set of questions to validate identity, customers can continue to speak about why they’re calling in while the system validates the caller's identity with a unique voiceprint designed to meet the precision level required by the organization. This also means that if a call drops and the customer calls back, the conversation can seamlessly resume. Connect customer conversations to the enterprise Conversational agents and human representatives work best when they can collaborate to resolve customer needs, and the customer conversation harness in Copilot Studio provides built-in handoff capabilities for different kinds of escalation paths to live representatives. Partner with your human agents in Teams Out of the box, the new harness has better support for partnering with your internal employees in Teams. You can escalate incoming calls to a Teams queue, and very soon directly to Teams chats. Think of a scenario: Oh, that’s an invoice coding issue, it should go to…Sally in accounting. And you can send that call to Sally with just a few clicks, right from within the UX. Or connect to your existing contact center When a full-fledged contact center is needed, connecting to one is simple. The new harness is designed to integrate seamlessly with our new Microsoft Contact Center Intelligence product and is also accessible within it. You can connect to your existing contact center, modernize your existing IVR systems and chat bots, partner with your existing human agents, configure advanced biometrics, score your calls, get insights on how your human-AI partnerships are working, and more - while retaining your existing telephony, routing, and queues. All with a few simple clicks. Govern agents with Microsoft Agent 365 Finally, like all Copilot Studio agents, these conversational agents are fully part of Microsoft’s Agent 365 governance story. Every agent built on the customer conversation harness will show up in Agent 365 upon creation. Admins should immediately see the details of the agent, including owner, channels, Entra agent ID, knowledge, tools, permissions, usage, etc. Centralized governance helps admins apply and update existing policies comprehensively across the enterprise. And, like the rest of Copilot Studio, the customer conversation harness uses Copilot Credits with usage-based billing, so it's easy to get started. Get started with the customer conversation harness With the new customer conversation harness in Copilot Studio, we're helping organizations build more natural, intelligent, and effective customer experiences - wherever they engage with customers. Many of these capabilities are available now in public preview, with more rolling out over the coming weeks. Together with the launch of our new Contact Center Intelligence offering, this is the first step in a journey to transform how everyone on the planet interacts with a brand. Head over to Copilot Studio, click "more ways to build" to try out our new customer conversation harness, and start changing how you engage with your customers today. For more information as you get started, explore the resources below: Learn how to build with the customer conversation harness Read about Microsoft Contact Center Intelligence
STAR: A Simple Way to Choose the Right Microsoft Copilot Studio Architecture
STAR: A Simple Way to Choose the Right Microsoft Copilot Studio Architecture One of the biggest challenges when building AI agents isn't creating the agent itself. It's choosing the right architecture for what you want the agent to accomplish. Should you use the Standard harness? The GitHub Copilot harness? Extend Microsoft 365 Copilot Chat? Build an application around your agent? Or create a voice-driven experience? These options serve different purposes. Choosing the wrong starting point can introduce unnecessary complexity and rework. I use a simple mnemonic called STAR to organize four important architectural considerations when designing solutions with Microsoft Copilot Studio. STAR stands for: S: Standard harness T: Task-oriented automation with the GitHub Copilot harness A: Application experiences R: Real-time voice experiences STAR is my own decision-making mnemonic, not an official Microsoft framework. Let's explore each option. S: STANDARD HARNESS When predictability matters The Standard harness is a useful starting point for agents that follow defined topics, instructions, conditions, and conversational paths. Consider an internal knowledge agent that answers questions using approved enterprise information and follows predefined workflows for specific tasks. The Standard harness lets you structure the conversation and control behavior through the components you configure. Consider this approach when: The process follows predictable steps. You need structured conversations and defined paths. The agent relies on established topics, prompts, and knowledge. You want to control the experience through explicit configuration. The principle is simple: when the process is predictable, a structured architecture can be the right choice. Official documentation: https://un5hru1qgj43w9rdtvyj8.subtlesoundimmersion.net/en-us/microsoft-copilot-studio/harnesses-overview 2.T: TASK-ORIENTED AUTOMATION WITH THE GITHUB COPILOT HARNESS When the agent needs to reason, plan, and execute Some tasks cannot be described as a simple sequence of predefined conversation paths. An agent might need to inspect multiple files, gather information from different sources, invoke several tools, evaluate intermediate results, and adjust its approach as the task progresses. The GitHub Copilot harness in Microsoft Copilot Studio is designed for this kind of reasoning-heavy execution. Despite its name, this is a Copilot Studio agent runtime, not the GitHub Copilot coding assistant. Depending on the configured capabilities, an agent can use tools, knowledge sources, MCP servers, connected agents, skills, and memory to accomplish a task. For example, an agent could analyze business documents, extract relevant information, prepare a structured summary, and generate an output file. Consider this approach when: The task involves multiple reasoning steps. The agent needs to work across several tools or information sources. File creation, editing, or analysis is important. The execution path may change based on intermediate results. You want to automate a complex business process. The key distinction is adaptive, multi-step execution rather than relying exclusively on predefined conversational paths. Official documentation: https://un5hru1qgj43w9rdtvyj8.subtlesoundimmersion.net/en-us/microsoft-copilot-studio/harnesses-overview 3.A: APPLICATION EXPERIENCES When a conversation is not enough Sometimes, the requirement is not simply to build an agent that answers questions. You need an application experience around the agent. This could include interactive components, structured data, custom layouts, dashboards, forms, and controls that let users work with information visually. Microsoft Copilot Studio Apps provide an application-oriented approach to creating experiences around agents and their capabilities. Depending on the requirements, developers may also use technologies such as SharePoint Framework (SPFx) to build custom components and integrate agent capabilities into SharePoint experiences. Imagine an AI-powered project workspace where users can ask questions, review generated insights, interact with structured information, and use custom interface components. The agent provides reasoning and conversational interaction, while the application provides the surrounding user experience. Consider an application-oriented architecture when: Users need more than a chat interface. The solution requires custom interactive components. Structured information needs to be presented visually. The experience must integrate with an existing application or SharePoint environment. You need greater control over the surrounding interface. The important question is whether users need a conversation or an application powered by an agent. Official documentation: https://un5hru1qgj43w9rdtvyj8.subtlesoundimmersion.net/en-us/microsoft-copilot-studio/apps-experience/apps-overview 4.R: REAL-TIME VOICE EXPERIENCES When interaction happens through speech Some agent experiences begin with spoken conversation rather than a typed prompt. Voice introduces additional architectural considerations, including speech processing, turn-taking, response timing, and conversational context. Microsoft Copilot Studio supports voice experiences, with available capabilities depending on the selected configuration and deployment channel. When designing a voice-driven solution, consider the entire interaction rather than simply converting text responses into speech. For example, an agent might need to understand spoken instructions, retrieve relevant information, perform a task, and communicate the result naturally. Consider a voice-oriented architecture when: Spoken interaction is a core requirement. Users need hands-free interaction. The solution depends on natural conversational turn-taking. Speech and conversation management are central to the experience. Voice is an interaction and deployment consideration rather than a direct equivalent of the Standard or GitHub Copilot harness. Confirm which capabilities are supported for your intended scenario. Official documentation: https://un5hru1qgj43w9rdtvyj8.subtlesoundimmersion.net/en-us/microsoft-copilot-studio/ WHAT ABOUT THE COPILOT CHAT HARNESS? STAR organizes four architectural considerations, but another important option is the Copilot Chat harness. This harness is designed to extend Microsoft 365 Copilot Chat with organizational knowledge so employees can obtain grounded answers within their existing Microsoft 365 experience. For example, an organization might want employees to retrieve information from approved internal knowledge without building an entirely separate application. In that case, extending Microsoft 365 Copilot Chat may be a better fit than creating a standalone agent experience. Consider it when the primary objective is to bring organizational knowledge into Microsoft 365 Copilot Chat. Official documentation: https://un5hru1qgj43w9rdtvyj8.subtlesoundimmersion.net/en-us/microsoft-copilot-studio/harnesses-overview QUICK DECISION GUIDE Structured conversations and predictable paths: Consider the Standard harness. Complex, multi-step tasks involving reasoning and tools: Consider the GitHub Copilot harness. Extending Microsoft 365 Copilot Chat with organizational knowledge: Consider the Copilot Chat harness. Custom application experiences and interactive components: Consider Copilot Studio Apps or a suitable custom application. Custom SharePoint interface components: Consider SharePoint Framework (SPFx), where appropriate. Speech-driven interaction: Consider a supported Copilot Studio voice experience. These options do not all belong to the same architectural layer. The Standard, GitHub Copilot, and Copilot Chat harnesses are runtime options. Applications and SPFx shape the user experience. Voice describes an interaction channel and its associated capabilities. A solution may combine multiple options when the selected technologies support the intended architecture. ARCHITECTURE BEFORE IMPLEMENTATION When planning an AI solution, it is tempting to start with whichever feature looks most impressive. A better approach is to begin with the work the solution must perform. Ask four questions. First, how predictable is the task? If the process follows established rules and paths, start by evaluating the Standard harness. Second, how much reasoning and adaptation does it require? If the agent must work through a complex objective involving multiple tools and intermediate decisions, evaluate the GitHub Copilot harness. Third, what experience do users actually need? If they need interactive components, structured information, or a custom application, consider the application layer separately from the agent runtime. Fourth, how will users interact with the solution? Determine whether the experience belongs in Microsoft 365 Copilot Chat, a custom application, a supported voice channel, or another appropriate deployment surface. These questions help establish the architecture before investing time in implementation. FINAL THOUGHTS Microsoft Copilot Studio offers different approaches to building agents and delivering experiences. The challenge is knowing which combination makes sense. My STAR mnemonic provides a simple starting point. S: Standard for structured execution. T: Task-oriented automation for complex, multi-step work. A: Applications for richer user experiences. R: Real-time voice for speech-driven interaction. The Copilot Chat harness is another option when the goal is to extend Microsoft 365 Copilot Chat with organizational knowledge. STAR is not about choosing the most advanced technology every time. It is about choosing an architecture that matches the task, the users, and the experience you want to build. How do you decide between a structured agent, a multi-step workflow, and a custom application experience when designing your next Copilot Studio solution? ABOUT ME! Sapan Patel AI Agent Developer | Microsoft Copilot Studio | Cowork | Power Platform | Azure AIUnderstand the Copilot Studio app-building harness
The first important distinction is that building an app is different from building a conversational agent. An app provides an interactive user interface. An agent reasons about a request and may use tools to accomplish a task. A workflow executes defined business logic. You can combine all three in a business solution. Component Responsibility Example Copilot Studio Apps User interface and application experience An employee service dashboard GitHub Copilot harness AI-powered building and orchestration runtime Planning multi-step tasks and generating app components Agent Reasoning and task execution Investigating a service request Workflow Repeatable business process Routing an approved request Data layer Stores and retrieves business information Requests, users, approvals, and status Connectors and APIs Integrates enterprise systems SharePoint, Microsoft Graph, or ServiceNow The GitHub Copilot harness in Copilot Studio is not the same thing as using the GitHub Copilot service. It is a Copilot Studio runtime for advanced reasoning and orchestration. Microsoft's documentation states that the normal Copilot Studio security, privacy, compliance, and data residency commitments continue to apply. 2. Before building: define the application properly One of the biggest mistakes is asking the builder to create an app with a vague prompt. For example: Weak prompt "Build an employee management app." This leaves too many decisions to the AI. It might generate an attractive interface but miss important business requirements. Instead, define these eight elements before generating the application. Element What to specify Business problem What problem does the application solve? Target users Who will use it? User journeys What tasks must users complete? Data model What entities, fields, and relationships are needed? UI requirements What screens, components, filters, and interactions are required? Business rules What validations and conditions must be enforced? Integrations What APIs, data sources, and systems are involved? Security Who can view, create, edit, approve, or delete records? Also define the acceptance criteria before generation. For example: Users can search requests by ID, owner, status, and date. Selecting a request opens its detailed view. Users can update permitted fields. Invalid status transitions are rejected. Loading, empty, and error states are handled. Changes are persisted to the intended data source. My recommendation: Write the requirements first, then build the app. Don't use repeated prompts to discover the business requirements while simultaneously generating the UI. 3. Step-by-step guide to building an app Step 1: Open the app-building experience Open copilot studio Step 2: Start with a complete application specification Let's use an example: an Enterprise AI Operations Dashboard. The app will help employees and administrators monitor AI automation requests, investigate failures, track processing time, and manage remediation. Start with a structured prompt. Master app-generation prompt You can adapt this prompt for your first build. Build a professional enterprise application called Enterprise AI Operations Dashboard. BUSINESS OBJECTIVE Create a centralized interface for monitoring AI automation requests, execution outcomes, failures, processing time, and remediation activities. TARGET USERS Operations analysts who monitor executions. Administrators who investigate failures. Managers who review operational performance. APPLICATION STRUCTURE Create the following pages: Overview Dashboard Total executions Successful executions Failed executions Success rate Average processing time Execution trend over time Recent failures Status distribution Execution Explorer Search by execution ID Filter by status, application, owner, and date Sort by execution time and duration Paginated or appropriately limited results Select an execution to open its details Execution Details Execution ID Application name Initiated by Start time and end time Duration Status Error summary Diagnostic information, when available Remediation history Remediation Center Display unresolved failures Allow authorized users to assign an owner Add investigation notes Update remediation status Record timestamps for changes Settings Configurable filters and display preferences Clear explanation of administrative permissions No destructive administrative actions without confirmation DATA MODEL Create a logical data model containing: Execution: ExecutionId ApplicationName InitiatedBy StartTime EndTime DurationSeconds Status ErrorSummary Environment RemediationStatus Remediation: RemediationId ExecutionId AssignedTo Notes Status CreatedAt UpdatedAt Define a relationship between Execution and Remediation. If a persistent data source is not configured, use clearly identified sample data. Do not present sample data as live production data. UI AND DESIGN Use a clean, modern enterprise dashboard with: Clear visual hierarchy Readable typography Consistent spacing Responsive layouts Accessible contrast Reusable UI components Summary cards Appropriate charts Searchable and filterable tables Clear loading, empty, success, and error states FUNCTIONAL REQUIREMENTS Search and filters must work. Dashboard metrics must be calculated from the underlying dataset. Selecting a row must display the corresponding execution details. Form inputs must be validated. Status changes must update the intended data source. Display clear error messages when operations fail. Prevent duplicate submissions where appropriate. Confirm potentially destructive actions. Preserve filters when navigating between related screens where feasible. SECURITY Respect the signed-in user's permissions. Do not expose secrets, access tokens, or sensitive diagnostic information. Do not rely on hiding a UI button as the only authorization control. Enforce authorization at the data source or API. Do not create external integrations without explicitly identifying their requirements. IMPLEMENTATION PROCESS First, summarize the proposed architecture, data entities, pages, and assumptions. Ask clarifying questions if a critical requirement is ambiguous. Then generate the first functional version of the application. After generation, test the primary user journeys and identify incomplete functionality. Clearly distinguish implemented features, simulated features, and integrations that still require configuration. This is a starting specification, not a guarantee that every requested capability will be generated correctly. Inspect the resulting application and verify its actual behavior. Step 3: Review the generated application Once the app preview appears, don't immediately ask for more features. First, inspect the application against the specification. Check: Does the navigation work? Are the pages connected logically? Do the tables display consistent data? Do the filters actually change the results? Are dashboard metrics calculated correctly? Does selecting a record open the correct details? Do forms validate required fields? Does saving actually persist the changes? Are the displayed integrations real or simulated? This distinction is essential: a functional-looking interface is not proof of a working backend. Microsoft's app-building experience provides an interactive preview and lets you refine the app through conversation. It also exposes the underlying code for inspection. 4. Technical prompting techniques for better apps This is where you can significantly improve the quality of generated applications. Technique 1: Build in controlled iterations Avoid asking the builder to implement every feature, integration, chart, and workflow in one enormous request. Use a sequence of targeted changes. Iteration 1: Application foundation "Review the generated application and identify missing requirements. Fix the navigation structure, page layout, data model, and core interactions before adding new features." Iteration 2: Data integrity "Review the application data model. Ensure each execution has a unique identifier, remediation records reference valid executions, and dashboard metrics are calculated from the underlying records. Identify any assumptions that require confirmation." Iteration 3: UI quality "Improve the visual hierarchy, spacing, typography, responsive behavior, table readability, and empty states. Preserve existing functionality and data relationships." Iteration 4: Functional behavior "Test search, filtering, sorting, record selection, form validation, and save operations. Fix broken interactions. Do not replace functional data operations with hardcoded sample results." Iteration 5: Error handling "Add appropriate handling for failed API requests, unavailable data, validation errors, empty results, and repeated submissions. Provide useful user-facing messages without exposing secrets or internal stack traces." Iteration 6: Final verification "Compare the application against the original requirements. List each requirement as implemented, partially implemented, or not implemented. Identify any feature that uses mock data or still needs external configuration." This approach makes failures easier to isolate and reduces the risk of breaking working functionality during a large rewrite. Technique 2: Specify behavior, not just appearance A prompt such as: "Add a modern search bar." defines appearance, not behavior. A better instruction is: "Add a search field above the execution table. Search across ExecutionId and ApplicationName. Apply the search when the user submits or after a short debounce. Combine the search with existing status and date filters. Show an empty state when no records match. Provide a clear-search action and preserve the selected sort order." The second instruction describes expected behavior, interaction, and edge cases. Technique 3: Define invariants An invariant is a condition that must remain true throughout the application. Examples: Every remediation record must reference an existing execution. Execution IDs must be unique. Failed executions must not be marked successful merely because a remediation note was added. A user cannot approve their own request if the business policy prohibits it. Dashboard metrics must use the same filtering rules as the displayed data. Failed writes must not display a false success notification. Add important invariants to the application specification and ask the builder to preserve them during modifications. Technique 4: Request minimal changes When fixing a specific problem, avoid asking the builder to regenerate the entire application. Instead, use an instruction such as: "Fix the execution table's date filter. Preserve the existing navigation, data model, styling, and other filters. Change only the logic needed to make the date filter work. Verify that it works independently and in combination with the status filter." This helps reduce unintended changes and makes troubleshooting easier. Technique 5: Ask for evidence of completion Don't accept a statement that a feature is complete without testing it. Ask: "Identify the implementation for this requirement, test the relevant user journey in the preview, and report any remaining limitation. If the functionality depends on an unconfigured API or connector, identify that dependency explicitly." Where the preview does not allow a test to be performed, request a clear statement of what remains unverified. 5. Underlying code: what to inspect Copilot Studio's app authoring experience includes a way to switch between the interactive preview and the underlying code. Use that capability to inspect the implementation rather than treating the generated UI as a black box. A. Component structure Look for whether the application separates responsibilities into logical components, such as: Navigation Dashboard cards Charts Data tables Search and filter controls Detail views Forms Notifications Loading and error states A large application that puts everything into one component can become difficult to maintain. Prompt: "Review the application structure and identify opportunities to separate repeated UI patterns into reusable components. Refactor only where the current authoring environment supports it, and preserve the existing behavior." B. State management Check how the app manages: Selected records Active filters Search terms Form values Loading states API errors Unsaved changes For example, changing the status filter should not unexpectedly clear the search term or cause the selected record to display stale data. Prompt: "Review state management for the search, filter, table, and detail views. Prevent stale selections, inconsistent filters, and UI updates that occur before a save operation succeeds." C. Data access Identify whether each data source is: Hardcoded sample data Local application state A configured connector A REST API A persistent business data source For production applications, ensure the data access layer has clear responsibilities and that failures are handled consistently. Prompt: "Identify every data source used by the application. Classify each as sample data, local state, or a live integration. Do not imply that data is persisted if it exists only in memory." D. Security Inspect the implementation for: Sensitive values embedded in client-side code Authorization implemented only through UI visibility Excessive data exposure Missing validation Unrestricted destructive operations Unclear handling of user identity Never place API secrets or privileged credentials in browser-accessible code. For sensitive operations, authorization must be enforced by the relevant backend or data source, not just by the interface. Important: Access to the app and access to its underlying data are separate concerns. Microsoft's documentation explains that apps use the signed-in user's identity when connecting to organizational data, and sharing an app does not automatically grant access to data the recipient otherwise cannot access. 6. Connecting the app to enterprise systems For a Microsoft enterprise scenario, you might need to connect the app to SharePoint, Dataverse, Microsoft Graph, Power Automate, or an internal API. The appropriate integration depends on the operation and the capabilities supported by the app-building environment. Requirement Possible integration Technical consideration Store business records Dataverse Define tables, relationships, permissions, and validation Read or update SharePoint items SharePoint connector or API Respect site and item permissions Retrieve Microsoft 365 information Microsoft Graph Configure authentication, consent, and least-privilege permissions Execute deterministic business logic Power Automate or an appropriate workflow Handle failures, retries, and duplicate requests Integrate a custom enterprise system REST API or supported connector Define authentication, schemas, and error contracts Use agent reasoning Copilot Studio agent Restrict tools and define clear instructions These are architecture options, not a claim that every integration is automatically configured by the app builder. Recommended architecture For an enterprise application, consider the following logical design: User ↓ Copilot Studio app and UI ↓ Approved application actions ↓ Connector, workflow, or API ↓ Business data source Where reasoning is required, the app can also invoke an appropriately configured agent. Keep responsibilities separate: UI: Collect input and display results. Business logic: Enforce validation and business rules. Agent: Handle tasks that benefit from reasoning. Workflow: Execute predictable, repeatable steps. Data source: Persist records and enforce applicable access controls. For example, an AI-generated remediation recommendation can be presented in the UI, but changing a production system should require an authorized action and the appropriate validation. 7. App testing: use a structured checklist Before publishing, test the main user journeys, not just the visual design. Test category Example test Functional Can the user create, view, and update a record? Validation Does the app reject a missing required field? Data integrity Does a remediation reference the correct execution? Filtering Do search and status filters work together? Error handling What happens when the API returns an error? Persistence Does the update remain after refreshing or reopening the app? Authorization Can an unauthorized user perform a restricted action? Accessibility Are controls labelled and keyboard-accessible? Responsive design Does the layout remain usable at narrower widths? Performance Does the interface remain responsive with realistic data volumes? Security Are secrets excluded from client-side code? Data integrity under failure Does a failed write avoid displaying a false success message? For each critical requirement, define an expected result and test it. For an application that modifies business data, also test repeated submissions, concurrent updates, and partial failures where applicable. 8. Optimize Copilot Credits and iteration time App creation, previewing, testing, and refinement can consume Copilot Credits. Microsoft documents usage-based billing for the app-building experience. These practices can help reduce unnecessary iterations. Write a complete specification first. Resolve critical questions about users, data, and business behavior before generation. Generate a minimum viable application. Start with the core pages and one complete user journey. Fix related problems together. Instead of making five separate requests for spacing, typography, card alignment, and table readability, group those visual changes into one clearly scoped request. Avoid unnecessary full rewrites. Ask for a targeted fix and explicitly preserve unrelated functionality. Separate requirements from optional enhancements. Finish the core user journey before adding animations, elaborate charts, and secondary features. Reuse a master specification. Keep the requirements, data model, and acceptance criteria in a reusable document so you don't need to reconstruct them for every iteration. Verify before requesting another change. Test the current result first. Otherwise, you may spend credits fixing an issue that no longer exists or introduce a new issue while fixing an old one. These are practical optimization strategies, not a guarantee of a particular percentage reduction in credit consumption. 9. Publishing and sharing the application Once the app has passed its tests: Review the final UI and application behavior. Confirm that sample data is clearly distinguished from live data. Verify configured connections and permissions. Test the intended user experience. Use the available publish action to publish the app. Share it with the intended users or groups. Verify access with an appropriately authorized test account. Document known limitations and outstanding integrations. The preview status matters. Microsoft explicitly notes that Apps in Copilot Studio is a preview feature, which may have restricted functionality and is not intended for production use. Therefore, don't assume that a successful preview or publishing action alone makes the application suitable for production. Confirm the current feature terms, organizational approval, and production-readiness requirements before deploying it for business-critical use. My final recommendation For your work with Copilot Studio, Power Platform, Cowork, MCP integrations, and enterprise automation, I would develop a reusable App Builder Playbook with five parts: A requirements template. A master app-generation prompt. A reusable set of UI and data-model refinement prompts. A testing and security checklist. A credit-optimization and publishing checklist. That gives you a repeatable engineering process instead of relying on trial-and-error prompting for every new app. The most important principle is this: use natural language to accelerate implementation, but use engineering discipline to verify the result.How to preserve document format and structure with Copilot Agent
Hi everyone, I was building a copilot agent that should be able to accept a document and then make changes to it before returning the new version of that document, which has the same format and structure as the original. What is the best way to accomplish this in copilot studio? So far, I have tried using a power automate flow and external tools but it seems that there is no free included tool that can achieve this task. All the document writing tools seem to be paid services requiring API keys. Is there an alternate free way of achieving this task? Thank you
Help building an Agent Flow to access specific folders in Sharepoint
Hi all, I am building an agent that needs to access specific subfolders (based on folder identifier) and then analyse this folder against the instructions for the agent. The planned flow is: User enters folder identifier (e.g. Vehicle registration number) The CoPilot Studio Agent uses an Agent Flow to find the Registration number folder within the SharePoint repository (which contains many folders for different cars). The Agent Flow helps the agent access the specific car's folder. The agent runs the instructions for this specific car, analysing the subfolders (e.g. Insurance documents, fuel expense history) to return to the user the outcome of the analysis for each subfolder within that registration's folder. My issue is getting the SharePoint access Agent Flow to work. I have tried using CoPilot chat to assist, but it gives a million different ways to accomplish the same thing. I understand that I need to trigger the flow, using "CarReg" as the input. Then I can use Get Files (Properties Only) to return and filter by folders to find the car registration. But now I only have the folder names, and not the underlying files for my agent to use. Also, once I perform the filter to get the relevant folder, I have many options of passing this back to the agent, such as via HTML tables or Compose. Is there a preferred method? Thanks, H777
Credits usage for Copilot Studio Workflow with agents
If I add an agent(for research and analyze from the JSON provided) in Copilot studio recurring workflow, whose and which credits will be used whenever it runs? Hi Team, I have a question regarding licensing and credit consumption in Copilot Studio. I have created a Copilot Studio agent that performs research and analysis based on a JSON payload. I am planning to invoke this agent from within a Copilot Studio recurring workflow that runs on a schedule. Could you please clarify the following: When the recurring workflow executes and calls the agent, whose credits are consumed? The user who created the workflow? The owner of the agent? The account under which the workflow runs? The environment's pooled credits? Are there separate credit charges for: Workflow execution Agent invocation Generative AI/research actions performed by the agent Any guidance or documentation links explaining the credit consumption model for this scenario would be greatly appreciated. Thank you!Managing apps built in Copilot Studio
Last week we announced app building in Copilot Studio and Copilot Cowork. Makers can now describe business outcomes and produce full-stack apps with built-in source control, deployment stages, and version isolation—all on Microsoft-hosted infrastructure that requires no infrastructure provisioning, hosting configuration, or deployment pipeline. With those capabilities built in, your administrative scope is narrower and more familiar. Apps are created in the maker's personal developer environment following the environment routing policies you already have. That means things like connector permissions and data policies apply to an app both while it is being built and after it is published. Apps also access connected data on behalf of the signed-in user, which means publishing or sharing an app never grants anyone access to data they could not already reach. With these new capabilities, there are three things that every admin should be thinking about: Review your app estate Control cost with credit caps Choose where makers can build apps Review your app estate Published apps are inventoried in the Microsoft 365 admin center. Each app shows: Who built it Its lifecycle state Which data sources and connectors it uses Which policies apply to it Usage and operational metrics From the same experience, you can also block or disable a published app, remove a connector, bring an app back within policy, control whether it can be shared, and retire apps that are no longer used. Control cost with credit caps Building and running apps are both charged through Copilot Credits usage-based billing, and are metered as two separate services. This distinction lets you manage maker cost and app runtime cost independently. Build consumption varies with the language model used, the complexity of the app, and how much iteration is involved. Runtime consumption, on the other hand, varies with the volume and complexity of the tasks the app processes. At runtime, if the user holds a Power Apps Premium license, usage is included within existing request limits. Beyond those limits, or without a license, usage bills through Copilot Credits. You can learn more by reviewing the Copilot Credits licensing guide. As an admin, you can define credit cap policies to manage your costs. For both maker and runtime usage, caps are set per user, and the controls are managed through usage-based billing. For makers, think of a cap as a per-user budget: you can set the same budget for everyone, or different budgets for groups of users, such as departments that carry separate budgets of their own. Choose where makers can build apps By default, app creation is available to all users in both Copilot Studio and Copilot Cowork. However, you may want to limit where people can build apps. To do so: In the Microsoft 365 admin center, navigate to Apps, then Overview, and find ‘Choose where people can make apps’. Two paths appear: Copilot Studio, where makers build directly, which is on by default and recommended Copilot Cowork, where people create apps through chat, with availability managed by your organization's participation in the Frontier program Note that turning a path off prevents new apps being created that way. However, apps that are already published through that path will continue to run. Key takeaways for managing apps built in Copilot Studio The Microsoft 365 admin center is the one place to review the app estate, adjust app policies, and decide which creation paths stay open. Set credit caps as per-user budgets today, uniformly or by group, and plan for environment-level caps as project budgets when they arrive. Decide who is accountable for overseeing published apps before makers start publishing, as you would for any other application estate. Go to the Microsoft 365 admin center
