Power Apps - development vs production
“It works fine in development.” Probably one of the most dangerous sentences in application development. 😄 I've seen Power Apps behave perfectly when we test with a small amount of data. Then the application goes to UAT or production and suddenly users start reporting: “It's taking too long to load.” “The gallery is empty.” “The search isn't returning everything.” “Why is this screen so slow?” Many times, the formula itself isn't the only issue. The data is. For example, an app might work perfectly with a few hundred SharePoint records. But as the list grows, the same approach can become a problem because of delegation and the amount of data being processed. That's why I've started asking these questions before finalizing an app: Is this query delegable? How much data will this list have after one year? Are we loading records into collections unnecessarily? Are we doing multiple LookUps inside a gallery? Can the filtering happen closer to the data source? Would Dataverse be a better option for this requirement? These questions don't always come up when we're building the first version of the application. But they become very important later. One thing I'm learning with Power Platform is that a solution that works today is not necessarily a solution that will scale tomorrow. Sometimes spending a little more time on the data and architecture in the beginning saves a lot of time later. Curious to know what others have experienced: What was the biggest Power Apps performance issue you faced after moving an application to production?
Large Dataverse Database Migration
Hello folks, Hoping someone has come across this challenge before - customer has a 1.5Tb+ prod database that needs to be reduced drastically. Is there a Support request route we can raise to create a DB copy into the customers Azure SQL? this would be the quickest route to get a copy before running bulk deletions. Long Term Retention wont be enough in this case either. Any thoughts welcome. TIA
Beta testers wanted — Dynamics Dynamo Kit, a Dataverse/CRM admin toolkit (free license as thanks)
Hi everyone, I've built Dynamics Dynamo Kit (DDK), a standalone admin toolkit for Dynamics 365/Dataverse environments. It's designed to speed up common admin tasks that usually mean custom scripts or manual digging, including: Security role & privilege auditing Risk/compliance scoring with actionable findings Duplicate record detection Environment health checks A setup wizard that configures the tool for your specific org instead of assuming one setup I'm looking for a few people who work with Dynamics 365 CE (Customer Service, Sales, or general admin work) to try it out and share feedback on: Whether it works as expected in your environment Anything confusing, broken, or slow Features you'd want that aren't there yet It's a portable app — no install required, just unzip and run. As a thank-you: beta testers who provide feedback will receive a free license when it launches, and (if you're up for it) a shoutout by name in the README as an early contributor. Interested? Reply here or send me a message and I'll get you a copy. Thanks in advance for any feedback!
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.
Guidance on Planner Premium, Dataverse and Power Automate
Hoping this title invites you to share more knowledge around Planner Premium, Dataverse and working with Automate Scenario: I have a user inside our company saying i need access to Dataverse since he wants to automate some task creation with regards to planner premium. I am pretty ok with that, so he needs a Power Automate Premium license. Although looking at the data in the Projects data tables in the default environment their business units are the root BU - getting a little concerned. Are all projects and related data available for all people that can read the Dataverse tables? If you have some insights or experience please comment :) Could they develop that in a development or sandbox environment before piping it to a designated environment? but there are no Projects tables in dev or in sandbox environment. Main problem: there's so much information about planner and power automate that it's impossible to actually find any guidance around this scenario amongst all classic planner hitsMicrosoft 365 & Power Platform Community call - Community demos
💡 Microsoft 365 & Power Platform Development bi-weekly community call focuses on different use cases and features within the Microsoft 365 and Power Platform - across Microsoft 365 Copilot, Copilot Studio, SharePoint, Power Apps and more. 👏 Looking to catch up on the latest news and updates, including cool community demos, this call is for you! 📅 On 18th of December we'll have following agenda: Copilot prompt of the week CommunityDays.org update Microsoft 365 Maturity Model update Latest on PnP Framework and Core SDK extension Latest on PnP PowerShell Latest on Copilot pro dev samples Latest on Power Platform samples Picture time with the Together Mode! Mike Givens (CACI) Automating smart Approval cancellations in Power Automate with Dataverse Ben Fetters (Peak Power Apps) – Creating a comments section in Canvas Apps with JSON Ejaz Hussain (Advania UK) – Integrate Copilot Agents into SharePoint: OOTB and Programmatic Approaches (Client API & WebChat) 📅 Download recurrent invite from https://aka.ms/community/m365-powerplat-dev-call-invite 📞 & 📺 Join the Microsoft Teams meeting live at https://aka.ms/community/m365-powerplat-dev-call-join 👋 See you in the call! 📖 Resources: Previous community call recordings and demos from the Microsoft Community Learning YouTube channel at https://aka.ms/community/youtube Microsoft 365 & Power Platform samples from Microsoft and community - https://aka.ms/community/samples Microsoft 365 & Power Platform community details - https://aka.ms/community/home 🧡 Sharing is caring!Microsoft Power Platform community call - December 2025
💡 Power Platform monthly community call focuses on different extensibility options for builders, makers and developers within the Power Platform. Typically demos are from our awesome community members who showcase the art of possible within the Power Platform capabilities. 👏 Looking to catch up on the latest news and updates, including cool community demos, this call is for you! 📅 On 17th of December we'll have following agenda: Power Platform Updates & Events Latest on Power Platform samples Supercharge Your Date Logic: The Ultimate Working Day Calculator for Power Automate – Ian Tweedie (Capgemini) Animated Navigation in PowerBI – James Mounsey-Moran (Trustmarque) Building a copilot for Dataverse DevOps – Shashank Bhide (Kerv Digital) 📅 Download recurrent invite from https://aka.ms/powerplatformcommunitycall 📞 & 📺 Join the Microsoft Teams meeting live at https://aka.ms/PowerPlatformMonthlyCall 👋 See you in the call! 📖 Resources: Previous community call recordings and demos from the Microsoft 365 & Power Platform community YouTube channel at https://aka.ms/community/videos Microsoft 365 & Power Platform samples from Microsoft and community - https://aka.ms/community/samples Microsoft 365 & Power Platform community details - https://aka.ms/community/home 💡 You want to do a demo in this call? - Please fill in the following form and we'll get you scheduled - https://aka.ms/community/request/demoAccess Releases 7 Issue Fixes in Version 2310 (Released October 25th, 2023)
Our newest round of Access bug fixes was released on October 25th, 2023. In this blog post, we highlight some of the fixed issues that our Access engineers released in the current monthly channel. If you see a bug that impacts you, and if you are on the current monthly channel Version 2310, you should have these fixes. Make sure you are on Access Build # 16.0.16924.20106 or greater.
