Guidance on licensing requirements for using managed environments
Is it sufficient to have a per-app premium licence assigned when using a managed environment or is a per-user premium licence required? I have read this guidance from https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-licensing "Every user running an app in a managed environment must have one of the following licenses: a Power Apps Premium, a Power Automate Premium license, or a Dynamics 365 Enterprise license that gives premium Power Apps usage rights *. If you use capacity-based licenses, a managed environment must have Power Apps per app plans such as app passes allocated to it. Use of Power Apps capabilities included with Dynamics 365 Pro licenses must be only within the context of the licensed Dynamics 365 application." Does the line that I have highlighted in red mean that you can in fact use per-app licences? or is this referring to something else? Thanks RosieIn a Day (XIAD) Partner Events Program - Train the Trainer Events (AgIAD, AIAD, AuIAD, PPIAD)
We invite you to attend an upcoming Train the Trainer session for Microsoft Partners to learn more about the In a Day (XIAD) Partner Events Program and how to lead workshops that empower customers to use and adopt Microsoft products. Our Train the Trainer events are designed to provide you with the knowledge and tools necessary to deliver successful Microsoft In a Day (XIAD) sessions. *Please note, participation is restricted to individuals representing a Microsoft Partner organization. You must register using your corporate email address that is associated with your Partner ID. Personal emails will not be approved. ✨ Why Attend? Expert Guidance: Learn from experienced trainers and get your questions answered. Comprehensive Resources: Access all the content and support you need to succeed. 📅 Upcoming Events: Agent in a Day Discover the basics of building agents with Microsoft Copilot Studio, including generative AI orchestration and integrating external data sources. More sessions coming soon! Recordings available on-demand. Inquire at xiadevents@microsoft.com App in a Day Explore the fundamentals of building apps with Microsoft Power Apps, including creating custom business applications without writing code. More sessions coming soon! Recordings available on-demand. Inquire at xiadevents@microsoft.com Automation in a Day Explore automation solutions with Power Automate, including creating workflows and automating business processes. More sessions coming soon! Recordings available on-demand. Inquire at xiadevents@microsoft.com Power Pages in a Day Get hands-on building simple, secure business websites with Microsoft Power Pages. More sessions coming soon! Recordings available on-demand. Inquire at xiadevents@microsoft.com 👉 Register for all upcoming sessions at https://aka.ms/xiadTTT/pp Partner with us! Are you a Microsoft Partner interested in the opportunity to join the program and deliver In a Day (XIAD) events? 🔍 Learn more about the program and review partner eligibility criteria: https://aka.ms/xiadpartneropportunity. 📧 Contact the XIAD Program team: xiadevents@microsoft.com 🚀 Get started today: https://aka.ms/XIADGetStarted 📤 Submit requests to deliver events: https://aka.ms/xIAD/PartnerEventsBridging the Skills Gap: Empowering Non-Coders to Automate Workflows in M365
Namstey Folks 🙏, As we look at digital transformation, one of the biggest bottlenecks is the skills gap in handling complex operational workflows. With the rise of modern M365 extensions and Power Platform capabilities, the barrier to entry is shifting. We can now build robust solutions directly inside SharePoint without needing heavy custom code. From what I’ve seen, the benefits of going the low-code/no-code route within the M365 ecosystem are clear: - Faster Deployment: Building internal workflows directly where teams already work cuts out weeks of standard dev cycles. - Empowered Teams: Operations teams can patch their own inefficiencies without waiting in a long IT queue. However, it also opens up real strategic questions around data governance, compliance, and keeping these citizen-developed solutions maintainable over time. How is your organization approaching upskilling for this? Are you training existing operational teams to build their own tools within the Microsoft ecosystem, or is IT still handling everything from the top down? Let's build robust solutionsPartner Case Study | Appfie and Plopsa
What does it take to keep a theme park running smoothly when thousands of guests are buying tickets, moving through gates, and making purchases every hour? While visitors experience the rides and attractions, a different kind of choreography is happening behind the scenes—one where finance teams work to keep every transaction accurate, aligned, and moving at speed. For teams smoothing out these back-end operations, having the option to deploy AI-powered, no-code or low-code solutions can be a game changer. And for Microsoft partner Appfie, this kind of operational challenge is an opportunity to rethink how work gets done. With their focus on no-code and low-code solutions, Appfie helps organizations replace fragmented processes with centralized, scalable systems built on Microsoft Power Platform. To support this work, Appfie taps into the Microsoft AI Cloud Partner Program for access to funding, tools, and direct collaboration with Microsoft experts to accelerate early-stage prototyping and align stakeholders faster. In addition, they highlight their Solutions Partner designations to establish credibility with customers and stand out from the competition in Microsoft Marketplace. By combining these program benefits with a mentorship-led delivery approach, Appfie empowers their customers to move quickly from idea to implementation while building internal capability along the way. This model proved especially effective when Studio Plopsa NV, the amusement park company, sought a faster, more consistent way to manage their core financial processes. Keeping every transaction on track across multiple parks Based in Belgium, Plopsa operates eight amusement parks across Europe, including in Belgium, Germany, and the Netherlands. The company is owned by family entertainment giant Studio 100, and their parks feature characters and locales from Studio 100 properties. Naturally, tracking financial transactions across ticket sales, events, souvenirs, food, and more is a monumental task. At the center of this effort was Plopsa’s main cash register process, a critical function that supports daily operations across all parks. As the business grew, managing this process in a consistent way became increasingly complex. This was especially true as the company was working with legacy technology—including, in some instances, pen and paper. Each location contributed to a shared financial picture, but without a centralized system, maintaining alignment across parks required additional effort and coordination. The lack of centralized data management also meant processes could vary from one park to another, creating inconsistencies in how data was handled and limiting visibility for the finance team. This fragmentation introduced friction into an otherwise smooth operational environment. Plopsa needed a solution that could be delivered quickly and that avoided disruptions to their fast-moving business. They weren’t looking for a lengthy transformation, but rather a way to modernize a core process and create a system that could deliver consistency, centralization, and speed. Their search for a solution led them to Appfie. Continue reading here
Why Your Copilot Studio Agent Fails in Production (And How to Fix It)
Most Copilot Studio tutorials show you how to build a chatbot. This post is about something harder: building agents that actually work in production. I architect enterprise agents at a hospitality company — handling customer email triage, HR workflows, helpdesk automation, and reporting pipelines across multiple systems. One of those agents reduced human handling time per customer email from ~12 minutes to under 2 minutes (88% reduction) by orchestrating sentiment analysis, CRM lookups, SOP research via child agents, and response drafting — all before a human agent ever opens the email. Here is what I've learned building at that scale. The Four Layers Every Enterprise Agent Needs Most teams design only the top layer and treat everything else as "we'll figure it out later." By the time the other layers become urgent — usually after an incident — they're too expensive to retrofit. Layer Component Conversation Topics · Entities · Adaptive Cards · NLU Orchestration Agent routing · Context passing · State Integration Connectors · Power Automate · Azure Functions Governance DLP · Auth · ALM · Monitoring · Logging Build the governance layer first. Design the conversation layer last. The demo will be slightly less impressive. The production deployment will be significantly more stable. The Three Mistakes I See Most Often 1. Slot-filling designed for the happy path The default Copilot Studio pattern collects parameters one by one. It breaks the moment your flow has conditional branches — which every real enterprise workflow does. Use intent-first routing instead: identify what the user wants before collecting any parameters, then branch to a sub-flow that collects only what that variant needs. 2. Multi-agent context that gets dropped When you delegate from a router agent to a capability agent, the receiving agent needs to know who the user is and what conversation state to preserve. Native session variables don't cross agent boundaries. Build an explicit context envelope — a JSON object passed at delegation time — that carries user identity, security scope, origin topic, and return context. Your agents become stateless with respect to each other. Context travels with the conversation. 3. No async pattern for slow integrations A synchronous request that works for a REST API returning in 200ms will silently fail for a legacy system query that takes 45 seconds. Design async from day one: submit to an Azure Service Bus queue, return a correlation ID, acknowledge the user, and use proactive messaging to deliver the result when it's ready. This is the single biggest gap between demos and production deployments. A Note on Authentication — Chatbots vs. Autonomous Agents This is a distinction most articles get wrong, so it's worth being explicit. Chatbots have a human on the other end of the conversation. Authentication options here include Entra ID SSO (works in Teams and SharePoint channels where the user's identity is delegated to the agent) or client ID + secret (validates against AD but without user delegation — the agent authenticates as itself, not as the user). Autonomous agents are different in a fundamental way: there is no human in the authentication loop. The agent authenticates using the identity of the account that owns and runs it. There is no SSO because there is no interactive user session. This distinction matters because the security model shifts entirely — you are no longer protecting a user session, you are protecting a service identity. This gets more interesting when your autonomous agent connects to non-Microsoft systems. There is no universal pattern here — it depends entirely on what the external system supports: - API Key / Secret — the most common pattern for SaaS integrations. The external system issues a scoped key specifically for this integration. Store it in Azure Key Vault or encrypted Power Platform environment variables, never hardcoded in a flow. The scoping question is critical: is this a full-admin key or a least-privilege key issued only for what this agent needs? - OAuth 2.0 Client Credentials (machine-to-machine) — the agent authenticates as itself using client ID + secret against the external system's auth server and receives a bearer token. No user involved, fully automated. - Basic Auth on legacy systems — still common in enterprise environments. Credentials must live in Key Vault, not in flow variables or connector configuration in plain text. - Custom connector with encrypted connection — Power Platform manages the auth at the connector level; credentials are stored encrypted and scoped to the environment. The governing principle across all of these: the identity the agent uses to call an external system should be issued specifically for that integration, scoped to only the permissions that agent needs, stored securely (Key Vault or encrypted environment variables), and auditable — meaning the external system's logs show the agent's calls as a distinct identity, not a shared admin account that 12 other things also use. Before You Go to Production — Quick Checklist [ ] Autonomous agent's owning account/service principal is scoped to least-privilege — access only to systems the agent needs, nothing broader [ ] Non-Microsoft system credentials stored in Azure Key Vault or encrypted environment variables — never hardcoded in flows [ ] Each external system integration uses a dedicated, scoped credential — not a shared admin account [ ] External system audit logs show the agent as a distinct, identifiable caller [ ] DLP policies configured per environment — production is strict, dev is permissive [ ] Dataverse schema finalized before topic design begins [ ] Error handling designed for every integration point with user-readable failure messages [ ] Async pattern in place for any integration that may take > 10 seconds [ ] ALM pipeline configured: Dev → Test → UAT → Prod with automated solution checker [ ] Application Insights connected with custom events for key agent actions [ ] Escalation rate baseline established with alert threshold configured The One Question to Ask Before Building Anything "What does success look like in six months, and what data does the agent need access to in order to achieve it?" That answer determines your Dataverse schema, your integration architecture, your authentication model, and your DLP policy — before a single topic is created. Agents designed from that question forward are maintainable and trusted by the business. Agents designed from the conversation layer down spend their first year in retrofitting mode. Happy to go deeper on any of these layers in the comments — particularly multi-agent context passing and the async pattern, which I find generate the most questions in enterprise deployments.Who Should Be Accountable for Data Quality in Dynamics 365: IT or the Business?
Data quality remains one of the most common challenges in Dynamics 365 environments, regardless of industry or organisation size. When customer records are incomplete, duplicate data exists, or reporting becomes unreliable, the conversation often turns to ownership and accountability. Consider a simple example: A sales team creates customer records in Dynamics 365, while customer service updates contact details and finance systems synchronize billing information through integrations. Over time, duplicate records appear, customer information becomes inconsistent, and management reports start showing conflicting results. When this happens, who is accountable? Are the business users entering the data? Is the IT team managing the platform? The integration owners? Or should there be dedicated data stewards responsible for maintaining data quality standards? Some argue that data quality is primarily a business responsibility because users create and maintain most of the information stored in Dynamics 365. Others believe IT teams should take greater ownership through governance frameworks, validation rules, integrations, monitoring, and automated controls. In practice, many organisations struggle to find the right balance. When data issues arise, responsibility can become unclear, making it difficult to drive long-term improvements. From your experience: Who should ultimately be accountable for data quality in Dynamics 365? Should ownership sit with business teams, IT, dedicated data stewards, or a shared governance model? What approaches have worked well in your organisation? Have you seen a particular governance model deliver better results? I'm interested in hearing different perspectives and learning how others are addressing this challenge.Is Power Automate Becoming the New Technical Debt in Dynamics 365 Projects?
Power Automate has transformed how organisations build automation within Dynamics 365 and the Power Platform. Teams can automate processes quickly, reduce manual effort, and deliver business value without extensive custom development. At the same time, I have noticed an interesting challenge in some organizations as Power Platform adoption matures. Over time, hundreds of flows can be created by different teams, often with varying levels of governance, documentation, and ownership. Business logic may become distributed across multiple automations, making troubleshooting, maintenance, and long-term support more complex. On the other hand, many organisations have successfully scaled Power Automate by implementing strong governance practices and automation standards. I'm interested in hearing different perspectives from the community. Have you seen Power Automate become difficult to manage at scale, or has it reduced technical debt in your organization? What governance, architecture, or operational practices have worked best for balancing innovation with maintainability?
Request to merge multiple Microsoft Learn certification IDs
Hello Microsoft Learn Support Team, I was advised by Pearson VUE and Microsoft Support to contact Microsoft Learn to request merging of my certification profiles. I have paid for the PL-900 exam, but the exam confirmation and status are not visible due to multiple Microsoft Learn IDs. The following Microsoft Learn IDs need to be merged: - ms1100781607 - ms1100998551 - ms1100999029 Kindly help merge these IDs and associate my PL-900 exam correctly. Thank you.Building Reliable AI Coding Workflows Using Modular AI Agent Optimization
Artificial Intelligence is rapidly transforming the modern software development industry. AI-powered coding assistants such as GitHub Copilot, Claude Code, and other Large Language Model (LLM)-based systems are helping developers automate repetitive coding tasks, improve productivity, and accelerate software development processes. These tools can generate code, assist with debugging, provide recommendations, and support developers during implementation. However, despite their growing capabilities, many AI coding assistants still face challenges related to reliability, maintainability, project-specific conventions, and structured software engineering workflows. Most coding assistants perform well for generic programming tasks but often struggle when working with domain-specific development requirements, API integrations, project architectures, validation workflows, and coding standards. In real-world software engineering environments, developers require systems that not only generate code but also follow project conventions, maintain readability, support modular development, and improve long-term maintainability. The project “AI Agents Optimization” focuses on improving the reliability and effectiveness of AI coding agents by designing structured workflows, modular configurations, validation mechanisms, and optimized task execution strategies. The objective of the project is to investigate how AI agents can become dependable collaborators in practical software engineering tasks instead of functioning only as autocomplete systems. The project explores different approaches for organizing AI agent workflows using structured instruction handling, modular task division, context management, validation systems, and integration of external tools and documentation sources. Different agent configurations are analyzed and evaluated to understand how workflow optimization affects software development quality and performance. Why Existing AI Coding Workflows Often Fail Most AI coding assistants perform well for isolated coding tasks but struggle in real-world engineering environments where projects involve multiple files, coding standards, APIs, validation requirements, and contextual dependencies. For example, a generic prompt such as: “Build authentication middleware” may generate functional code, but the output often lacks: Project-specific architecture Error handling consistency Validation logic Security best practices Dependency awareness This project approaches the problem differently by introducing a structured workflow pipeline where AI agents operate in defined stages rather than generating outputs in a single step. The workflow separates planning, generation, validation, and refinement into independent modules. This improves maintainability, reduces inconsistent outputs, and supports iterative refinement similar to real software engineering workflows. Project Objectives The primary objective of this project is to optimize AI coding agents for real-world software engineering workflows. The project aims to improve how AI systems handle development tasks such as code generation, debugging, testing, validation, feature implementation, and workflow management. Another major objective is to design modular AI workflows where different stages of software development are managed systematically. The workflow focuses on task planning, instruction processing, validation, refinement, and output evaluation. This structured approach improves transparency, maintainability, and consistency in AI-generated outputs. The project also aims to evaluate how AI coding agents perform under different configurations and development scenarios. By testing multiple workflows and structured instruction methods, the project analyzes how optimization techniques improve development reliability and coding quality. Technologies and Tools Used The project utilizes multiple modern technologies and development tools for experimentation and workflow optimization. Technology / Tool Purpose Python Automation and scripting GitHub Copilot AI-assisted coding Claude / LLM APIs AI workflow experimentation Visual Studio Code Development environment Git & GitHub Version control and repository management Structured Prompting Workflow optimization MCP Concepts Tool and context integration These tools collectively support the implementation and testing of optimized AI coding workflows. Implementation Workflow The system was implemented using a modular AI workflow pipeline where each stage performs a dedicated engineering task. Step 1 — Task Parsing The user submits a development task or coding requirement. The Instruction Processing Module extracts: Objective Constraints Project context Expected output format Example structured prompt: Task: Create JWT authentication middleware Language: Node.js Constraints: - Use Express.js - Add token validation - Follow modular architecture - Include error handling Step 2 — Planning & Reasoning The Planning Module divides the task into subtasks such as: Route handling Token verification Error management Security validation This improves reasoning consistency before generation begins. Step 3 — Code Generation The Code Generation Module produces outputs using structured prompts and contextual references instead of generic instructions. Step 4 — Validation Generated outputs are validated using: Syntax checks Logical consistency checks Formatting standards Dependency validation Step 5 — Refinement If validation fails, the workflow loops back into refinement where issues are corrected before final delivery. System Workflow The workflow of the AI Agents Optimization system is based on modular task execution and structured development processes. The workflow begins with task planning and requirement analysis. The AI agent receives structured instructions along with coding constraints, project context, and validation requirements. The system processes the provided instructions and generates outputs according to defined workflows and development standards. Different configurations are tested to evaluate how instruction structures and modular task handling influence the quality of generated code The workflow also includes validation and refinement stages where generated outputs are analyzed for correctness, maintainability, and consistency. The project focuses not only on code generation but also on improving readability, workflow transparency, debugging support, and adherence to project conventions. Key Features of the Project Structured AI workflow design Modular task execution AI-assisted software development Workflow optimization strategies Validation and refinement mechanisms Integration of development tools and documentation Improved maintainability and readability Support for practical software engineering workflows Challenges Faced During Development One of the major challenges encountered during the project was maintaining consistency and reliability in AI-generated outputs. Different AI models often produce different responses depending on prompts, context, and task structure. Designing workflows that improve output stability and maintain coding standards required careful experimentation and optimization. Another challenge involved integrating structured workflows while ensuring flexibility in task execution. AI systems often require clear instructions and contextual information to produce accurate outputs. Balancing automation with maintainability and project-specific requirements was an important aspect of the project. Managing validation and refinement processes was also challenging because generated outputs needed to be evaluated not only for correctness but also for readability, maintainability, and software engineering best practices. Observations and Outcomes During experimentation, structured workflows produced more reliable and maintainable outputs compared to single-prompt generation approaches. Some important observations included: Reduced repetitive corrections during code refinement Improved consistency in generated outputs Better adherence to coding structure and formatting More stable workflow behavior for multi-step tasks Improved readability and maintainability of generated code The validation and refinement stages were particularly effective in reducing incomplete outputs and improving response quality. Although the project focuses primarily on workflow architecture and qualitative analysis rather than benchmark testing, the results demonstrate that modular AI pipelines can significantly improve practical software engineering workflows. Future Enhancements The project can be further enhanced by implementing advanced multi-agent collaboration systems where multiple AI agents work together on complex software development tasks. Future versions may also include real-time documentation integration, automated testing frameworks, cloud-based workflow management, and improved reasoning models. Additional enhancements may include IDE extensions, intelligent debugging systems, automated code review mechanisms, and adaptive workflow optimization based on project requirements. Conclusion The AI Agents Optimization project demonstrates how structured workflows and modular configurations can improve the effectiveness of AI-powered coding assistants in modern software engineering environments. By focusing on workflow optimization, validation mechanisms, modular task execution, and structured instruction handling, the project highlights the future potential of AI agents as reliable development collaborators capable of supporting real-world software engineering processes. The project represents an important step toward building dependable AI-assisted development systems that improve productivity, maintainability, and software quality while supporting modern engineering practices. How to Try This Workflow Define a structured development task Provide project constraints and context Break the task into subtasks Generate output using structured prompts Validate output quality Refine based on validation feedback
