Service Principals in Microsoft Power Platform
Shared Passwords Are a Ticking Time Bomb Let’s be blunt: if your Power Platform automation runs on a shared service account password that three people know, you are one resignation away from every flow going dark, one password reset, one MFA change… That is all it takes. The fix? A service principal, a non‑human application identity in Microsoft Entra ID that authenticates with certificates, never logs in interactively, and keeps running no matter who leaves. In Power Platform, it shows up as an Application User in Dataverse and can own flows, manage Power BI datasets, run Dataverse operations, and power your CI/CD pipelines. Unlike a traditional shared service account (which carries the risk of password expiration, MFA prompts breaking automation, and credentials being overshared), a service principal authenticates using certificates or client secrets, has no mailbox, no interactive login, and cannot be accidentally used by a person. For organizations running Power Automate flows, calling APIs, running Power Platform Pipelines or managing environments programmatically, service principals offer a fundamentally more secure, auditable, and manageable identity. They enable least-privilege access, integrate cleanly with Conditional Access policies, and eliminate the single point of failure that comes with tying critical automation to an individual employee's account. This lack of tether to an individual account means workloads do not need to be reassigned once someone leaves your organization. Put more simply, if your Power Platform workloads are still running under a named user or a shared "svc_powerautomate@company.com" account, it's time to reconsider. Microsoft Advisory: “Best practice is to use service principals as the preferred identity model for Power Automate wherever supported, because shared user‑based service accounts introduce security, audit, and operational risks.” In this blog, we will highlight opportunities to strengthen your security posture across the Power Platform with Service Principals alongside ideas for when a Service Principal may not be applicable for your scenario. Getting Started: Setting up a service principal is straightforward. Everything is documented on Microsoft Learn: 🔗Register an app in Entra ID — Microsoft Learn 🔗Manage application users — Microsoft Learn 🔗Service principal owned flows — Microsoft Learn There are also many good blogs about step-by-step setup of the service principal, assigning permissions and assigning to an application user we won't be covering the setup here. Let's go into detail how you can utilize a Service Principal to secure your Power Platform workloads. Where Service Principals Shine in the Power Platform ⚡ Power Automate In Power Automate, service principals establish durable ownership and authentication for enterprise automation. Flows run under a non‑human application identity, eliminating dependency on individual users and preventing failures caused by password rotation, MFA enforcement, or user departure. Flow Ownership: Assign the service principal as the primary owner to ensure flows continue running regardless of personnel changes. Service Principal‑owned flows require either a Process license (~$150/flow/month, stackable up to 10 for 2.5M actions/day) or pay‑as‑you‑go billing via Azure. Authentication: Service principals authenticate using client credentials, removing the standard 90‑day connection expiry. Only the client secret or certificate has an expiration, which can be configured (up to 24 months). For production workloads, store secrets in Azure Key Vault with rotation alerts. Dataverse Connector: Dataverse is the only standard connector with native service principal sign‑in. Selecting Connect with Service Principal ensures all Dataverse actions execute under the application identity with full audit attribution. Non‑Service Principal Connectors: Connectors such as SharePoint, Outlook, and Teams require delegated user context by design. Where app‑only execution is required, the HTTP connector can be used to call Microsoft Graph with application permissions, introducing a premium dependency. ✓ Service Principal‑Friendly ✓ Microsoft Dataverse (native SP sign‑in) ✓ Custom connectors (app‑only OAuth) ✓ HTTP via Graph API (app permissions) ⚠ Requires User Context ⚠ SharePoint (standard connector) ⚠ Outlook / Office 365 ⚠ Teams (many actions) ⚠ Planner, OneDrive 🔗Support for service principal owned flows - Power Automate | Microsoft Learn 🔗 Manage connections to Dataverse — Microsoft Learn 📱 Power Apps and Dataverse Your Service Principal’s Application User executes Dataverse operations from flows triggered by model‑driven apps. Audit logs clearly separate automated changes from human activity. Assign custom security roles scoped to exact tables (skip System Admin), use separate Service Principalss per solution area, and know that canvas apps can trigger Service Principal‑backed flows behind the scenes. 🔗Create a Dataverse application user — Microsoft Learn 📊 Power BI This is where Service Principals quietly save organizations from one of the most common Power BI failures: dataset refresh breaking because the owner left. Take over semantic model ownership via the REST API and refreshes never fail from expired tokens again. Workspace access: add Service Principal as Member or Admin Semantic model ownership takeover via REST API Automated refresh from PowerShell, Logic Apps, Azure Data Factory, or custom apps XMLA endpoint access for model deployment and DAX queries (Premium/Fabric) App Owns Data embedding for external users without Power BI licenses Requirement: Tenant admin enables “Service principals can use Fabric APIs”. Service Principal added to workspace. API refresh needs Premium, Premium Per User, or Fabric capacity. 🔗Automate Premium tasks with Service Principals — Microsoft Learn 🔗Enhanced refresh REST API — Microsoft Learn 🛠️ Application Lifecycle Management (ALM) with Pipelines Power Platform Pipelines are a built-in option for application lifecycle management native to the Power Platform. Pipelines bring ALM automation and continuous integration and continuous delivery (CI/CD) functionality into a native service that's designed to be usable by all members of your low-code team, regardless of technical capability. To learn how to set up pipelines in Power Platform, Microsoft has some fantastic documentation as well as a learning path on Learn.microsoft to guide you through the process. We can utilize Service Principals in Pipelines as well. By default, a pipeline deploys as the requesting maker, meaning the maker needs elevated permissions to deploy to the target environment. Delegated deployments with Service Principals allow deployment without the maker needing elevated permissions in the downstream environment. The pipeline can run as a service principal (or pipeline stage owner), allowing makers to deploy without needing elevated permissions in target environments like production. Approvals may be required for security reasons, and can be automated or manual depending on your security requirements. 🔗PAC CLI: createserviceprincipal - Microsoft Learn 🛡️ Alternatives for Secure Workloads While service principals offer an avenue to securing most workload scenarios on the Power Platform, they cannot cover all workload scenarios. In these cases, there are alternative approaches. Azure Logic Apps support system-assigned and user-assigned managed identities, allowing workflows to authenticate directly to Azure resources without storing or managing any login credentials. This can offer an option when your workload can live outside Power Automate. Some teams opt to retain shared service accounts. This is not best practice, but when undertaken, there are steps to harden these accounts. Dedicated Entra Conditional Access policies to enforce MFA, restricting sign in locations and devices can provide additional protection. For password rotation, Azure Key Vault centralizes credential storage and enables automatic secret rotation, reducing the risk of stale or exposed passwords. Each of these approaches can be layered or combined with service principals depending on your organization's risk tolerance, licensing constraints, and connector support limitations. 🔗Governing Entra service accounts — Microsoft Learn All Your Options at a Glance Not sure which approach fits? Here is every option compared — from the gold standard to the fallback you hope to leave behind: Option MS Rec? Key Benefit Main Tradeoff Security SP + Process License Yes Gold standard. Certificate auth, clean audit. ~$150/flow/mo. Solutions required. Highest SP + Flow Groups Yes (GA May ’26) 1 license across up to 25 flows. Shared 250K/day action pool. Highest SP + Pay-as-you-go Yes Available today. No upfront cost. Variable cost. Azure sub needed. Highest Hybrid: SP + SA Pragmatic SP owns; SA for delegated connectors. SA still exists for connections. Med‑High Hardened SA Only No Simplest and no migration needed. Interactive login risk. MS discourages. Low Logic Apps + MI Yes (diff product) Zero credentials. Consumption billing. Full platform migration required. Highest ⚠ All costs are approximate and vary by enterprise agreement. Verify with your Microsoft representative. Microsoft‑validated: The dedicated service account fallback is a supported approach, not a workaround. Any alternative to service principals would need to be designed and accepted at the customer’s own risk. Summary Service principals replace shared, user‑based accounts with a non‑human application identity that is secure, auditable, and resilient. Eliminating password risk, improving governance, and ensuring Power Platform workloads continue running independent of employee lifecycle events across the entire platform. The result is higher security, operational stability, and governance consistency. The Bottom Line Service principals are not optional polish. They are how Microsoft expects you to run enterprise automation in 2026. One Entra ID app registration. Four products. Zero shared passwords. ✓ Blocking interactive admin logins is correct. No supported scenario requires it. ✓ Hybrid model when needed. Service Principals where supported, hardened service accounts where not. Both documented by Microsoft. ✓ Start with pay‑as‑you‑go. Pilot a batch. Measure costs. Then commit. No upfront purchase needed. Authors: Sheldon Dsouza + Marc Lotorto | Contributors: Rasha Al-Silmi, Ahmed Shaalan, Josh Flicker All guidance aligned with Microsoft Learn and validated by Microsoft Advisory, April 2026
Breaking the Shackles of Legacy Portals: Power Pages as Enterprise SaaS
It's time to stop building "Portals" and start deploying Enterprise SaaS. For years, enterprise teams building web portals have been shackled by rigid Dynamics 365 schemas and heavy, template-driven UIs. Traditional Power Apps Portals required developers to follow the portal's own schema structure—page templates, web forms, lists, content snippets—and inherit data models dictated by D365 modules. That era is over. Power Pages has evolved into a secure, enterprise-grade, low-code SaaS platform for creating, hosting, and administering business websites—and as of early 2026, two milestone GA releases have removed the last remaining constraints. Here are six ways those shackles are broken: 🎨 1. UI Liberation with Single-Page Applications — Now GA Single-Page Application support in Power Pages reached General Availability on February 8, 2026, starting with site version 9.8.1.x and later. Developers can now build fully custom, client-side rendered web applications using React, Angular, or Vue and deploy them directly to Power Pages using the Power Platform CLI. This is not a workaround or a bolt-on—Microsoft describes this GA release as making the SPA experience "production ready". What this means in practice: the traditional portal constructs—ASP.NET and Liquid templates, web forms, lists—become optional implementation details, not architectural constraints. Your UI is completely custom and API-driven, calling Power Pages Web APIs for all data operations. The GA release also resolved issues where Power Pages platform styles could override custom CSS, and included updated guidance for authentication configuration and local development setup. Developers can run SPAs locally with full authentication and Web API access, enabling JavaScript hot reload and local debugging without deploying changes to the portal on every iteration. At this point, the traditional portal schema becomes an implementation option—not a constraint. (Ensure your Power Platform CLI is on the latest version for full capabilities.) 🗄️ 2. Data Model Autonomy — Your Entities, Your Rules Power Pages connects to Microsoft Dataverse, but you are no longer forced to borrow a Dynamics 365 schema. Teams can design their own data model from scratch—whether it has five tables or hundreds with complex relationships—tailored to the business domain. Those custom Dataverse tables serve the SPA directly via Web APIs, without needing to build model-driven or canvas apps. This is a fundamental departure. The platform uses the same shared business data stored in Dataverse that other Power Platform components can leverage, but your portal is no longer tethered to any pre-existing Dynamics module. You own your entity model entirely. The result: headless CMS flexibility backed by the security and reliability of Dataverse, without the overhead of a CRM schema you didn't ask for. ☁️ 3. Fully Managed Platform — No Infrastructure Burdens Goodbye, custom web hosting and plumbing. Power Pages is a fully managed SaaS platform—Microsoft handles provisioning, hosting, CDN, scaling, and availability. Authentication is built in, with full support for enterprise identity providers including Microsoft Entra ID and Microsoft Entra External ID, along with table permissions and web roles enforcement on every API call. Organizations can also allow anonymous access or configure private sites as needed. Even advanced backend needs are now covered natively. Server Logic in Power Pages reached General Availability on April 1, 2026, delivering native server-side JavaScript execution with the maturity, governance, and extensibility required for enterprise production workloads. Alongside GA, Microsoft announced two enhancements that reinforce enterprise readiness: Governance control to disable external calls — administrators can restrict outbound connectivity from the Server Logic layer to comply with internal policies and regulatory requirements. Support for unbound Dataverse custom actions — enabling deeper integration with existing business logic layers. The result? Teams focus only on business logic, integrations, and user experience. As Hope Bradford, Senior Director of IT at Kelly Staffing, stated: "Power Pages lets us build personalized client experiences without managing complex infrastructure while maintaining enterprise trust and security." Kelly Staffing's Helix UX portal, built on Power Pages, Dataverse, and Power Automate, now handles over 38,000 client interactions per day. 🛡️ 4. Enterprise-Grade Security and Telemetry Security and governance are first-class citizens on the platform. The 2025–2026 release wave introduced enterprise-grade controls for Power Pages including role-based access and authentication through Entra, Data Loss Prevention (DLP) rules for external data access, IP-based restrictions, maintenance mode options, and built-in diagnostics and monitoring dashboards. Across the broader Power Platform, Microsoft is investing in enterprise observability—the April 2026 update introduced alerting and data metrics in Power Platform Monitor (covering metrics such as app open success rate, time to interactive, data request success rate, and data request latency), enabling IT teams to define health thresholds, receive proactive notifications, and take guided action. This level of governance—audit, monitoring, diagnostics—traditionally required significant custom engineering. Now it is out of the box. 💲 5. Scalable, Usage-Based Licensing One of the most significant licensing shifts: Power Pages became its own product, decoupling from Power Apps licensing entirely. Both internal and external users now fall under the same licensing model, making Power Pages viable for internal use cases like HR services and request management—not just external portals. The model is usage-based (Monthly Active Users), purchased as capacity packs per site: Authenticated Users (Pre-paid): $200 per site/month for 100 users Anonymous Users (Pre-paid): $75 per site/month for 500 users Authenticated Users (Pay-As-You-Go): $4.00 per user/site/month, on-demand Anonymous Users (Pay-As-You-Go): $0.30 per user/site/month, on-demand Each authenticated-user subscription plan includes 2 GB database capacity and 16 GB file capacity. For applications serving tens of thousands of users, this capacity-based model is strategically superior to per-user or per-app seat licenses. Pay-as-you-go costs roughly twice as much as pre-paid capacity packs but suits seasonal or unpredictable usage patterns (e.g., tax season, annual HR enrollment). Tradeoff to consider: Pre-paid packs require upfront commitment and do not roll over month to month, so organizations with highly variable traffic must carefully model usage to avoid over- or under-provisioning. ⚠️ Pricing disclaimer: The figures above are illustrative examples sourced from publicly available Microsoft documentation. Actual costs may vary based on customer type (enterprise vs. corporate), volume commitments, negotiated agreements, and account structure. Final pricing is determined through Microsoft account teams and contracts. ⚡ 6. Rapid Modernization with AI-Assisted Development Power Pages now integrates directly with AI-assisted development workflows. Microsoft announced the public preview of the Power Pages plugin for GitHub Copilot CLI and Claude Code on February 24, 2026, providing an AI-assisted workflow for creating, deploying, and managing modern SPA sites on Power Pages. Developers can scaffold pages, configure data access, and wire up logic using natural language commands, dramatically reducing the time to modernize large enterprise applications. SPAs are deployed using Power Platform CLI commands, and the entire development loop is designed to be streamlined for professional developers. This means that even large, complex in-house enterprise applications—hundreds of tables, complex relationships, tens of thousands of users—can be remodeled on Power Pages far more efficiently than legacy approaches required. You migrate your own custom model into Dataverse, build your SPA, wire up integrations, and the platform handles everything else. The Bottom Line If you are still managing custom Azure websites, maintaining SQL servers, or stitching together bespoke PaaS stacks for internal business tools, you are carrying unnecessary operational weight. Power Pages is no longer just a D365 portal. It is a fully managed, enterprise-grade SaaS platform that gives you total UI freedom (SPA support: GA since February 2026), native server-side logic (GA since April 2026), your own data architecture without D365 schema dependencies, built-in security and governance, and a licensing model that scales to enterprise volumes. The industry is underestimating this shift. The shackles are off. Deploy, don't build.Token Cache Service Inside D365 CE Plugin Base
Introduction This document explores a performance optimization technique for Dynamics 365 plugins by implementing centralized token caching using static variables in a plugin base class. Since plugin instances are recreated for every request, holding variables in memory is not feasible. However, static variables—such as a ConcurrentDictionary—defined in a base class can persist across executions, enabling efficient reuse of authentication tokens. This approach avoids tens or even hundreds of thousands of daily calls to identity management endpoints, which can overload those services. Additionally, plugin execution time can increase by 500 milliseconds to one second per request if authentication is performed repeatedly. **Token caching is neither a universal requirement nor a general best practice; its value depends on whether small latency reductions meaningfully compound at scale and materially reduce repeated authentication traffic against the identity provider—conditions that most implementations do not experience**. 🔐 TokenService Implementation for Plugin Token Caching To optimize authentication performance in Dynamics 365 plugins, a custom TokenService is implemented and injected into the plugin base architecture. This service enables centralized token caching using a **static, read-only **ConcurrentDictionary, which persists across plugin executions. 🧱 Design Overview The TokenService exposes two methods: GetAccessToken(Guid key) – retrieves a cached token if it's still valid. SetAccessToken(Guid key, string token, DateTime expiry) – stores a new token with its expiry. The core of the service is a static dictionary: private static readonly ConcurrentDictionary<Guid, CachedAccessToken> TokenCache = new(); This dictionary is shared across plugin executions because it's defined in the base class. This is crucial since plugin instances are recreated per request and cannot hold instance-level state. 🧩 Integration into LocalPluginContext The TokenService is injected into the well-known LocalPluginContext alongside other services like IOrganizationService, ITracingService, and IPluginExecutionContext. This makes the token service available to all child plugins via the context object. public ITokenService TokenService { get; } public LocalPluginContext(IServiceProvider serviceProvider) { // Existing service setup... TokenService = new TokenService(TracingService); } 🔁 Token Retrieval Logic GetAccessToken checks if a token exists and whether it’s about to expire: public string GetAccessToken(Guid key) { if (TokenCache.TryGetValue(key, out var cachedToken)) { var timeRemaining = (cachedToken.Expiry - DateTime.UtcNow).TotalMinutes; if (timeRemaining > 2) { _tracingService.Trace($"Using cached token. Expires in {timeRemaining} minutes."); return cachedToken.Token; } } return null; } If the token is expired or missing, it returns null. It does not fetch a new token itself. 🔄 Token Refresh Responsibility The responsibility to fetch a new token lies with the child plugin, because: It has access to secure configuration values (e.g., client ID, secret, tenant). It knows the context of the external service being called. Once the child plugin fetches a new token, it calls: TokenService.SetAccessToken(key, token, expiry); This updates the shared cache for future executions. 🧱 Classic Plugin Base Pattern (Preserved) public abstract class PluginBase : IPlugin { protected internal class LocalPluginContext { public IOrganizationService OrganizationService { get; } public ITracingService TracingService { get; } public IPluginExecutionContext PluginExecutionContext { get; } public LocalPluginContext(IServiceProvider serviceProvider) { PluginExecutionContext = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); TracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); OrganizationService = ((IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory))) .CreateOrganizationService(PluginExecutionContext.UserId); } } public void Execute(IServiceProvider serviceProvider) { try { var localContext = new LocalPluginContext(serviceProvider); localContext.TracingService.Trace("Plugin execution started."); ExecutePlugin(localContext); localContext.TracingService.Trace("Plugin execution completed."); } catch (Exception ex) { var tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); tracingService.Trace($"Unhandled exception: {ex}"); throw new InvalidPluginExecutionException("An error occurred in the plugin.", ex); } } protected abstract void ExecutePlugin(LocalPluginContext localContext); } 🧩 TokenService Implementation public interface ITokenService { string GetAccessToken(Guid key); void SetAccessToken(Guid key, string token, DateTime expiry); } public sealed class TokenService : ITokenService { private readonly ITracingService _tracingService; private static readonly ConcurrentDictionary<Guid, CachedAccessToken> TokenCache = new(); public TokenService(ITracingService tracingService) { _tracingService = tracingService; } public string GetAccessToken(Guid key) { if (TokenCache.TryGetValue(key, out var cachedToken)) { var timeRemaining = (cachedToken.Expiry - DateTime.UtcNow).TotalMinutes; if (timeRemaining > 2) { _tracingService.Trace($"Using cached token. Expires in {timeRemaining} minutes."); return cachedToken.Token; } } return null; } public void SetAccessToken(Guid key, string token, DateTime expiry) { TokenCache[key] = new CachedAccessToken(token, expiry); _tracingService.Trace($"Token stored for key {key} with expiry at {expiry}."); } private class CachedAccessToken { public string Token { get; } public DateTime Expiry { get; } public CachedAccessToken(string token, DateTime expiry) { Token = token; Expiry = expiry; } } } 🧩 Add TokenService to LocalPluginContext public ITokenService TokenService { get; } public LocalPluginContext(IServiceProvider serviceProvider) { // ... existing setup ... TokenService = new TokenService(TracingService); } 🧪 Full Child Plugin Example with Secure Config and Token Usage public class ExternalApiPlugin : PluginBase { private readonly SecureSettings _settings; public ExternalApiPlugin(string unsecureConfig, string secureConfig) { // Parse secure config into settings object _settings = JsonConvert.DeserializeObject<SecureSettings>(secureConfig); } protected override void ExecutePlugin(LocalPluginContext localContext) { localContext.TracingService.Trace("ExternalApiPlugin execution started."); // Get token string token = AccessTokenGenerator(_settings, localContext); // Use token to call external API CallExternalService(token, localContext.TracingService); localContext.TracingService.Trace("ExternalApiPlugin execution completed."); } private string AccessTokenGenerator(SecureSettings settings, LocalPluginContext localContext) { var token = localContext.TokenService.GetAccessToken(settings.TokenKeyGuid); if (!string.IsNullOrEmpty(token)) { var payload = DecodeJwtPayload(token); var expiryUnix = long.Parse(payload["exp"]); var expiryDate = DateTimeOffset.FromUnixTimeSeconds(expiryUnix).UtcDateTime; if ((expiryDate - DateTime.UtcNow).TotalMinutes > 2) { return token; } } // Fetch new token var newToken = FetchTokenFromOAuth(settings); var newPayload = DecodeJwtPayload(newToken); var newExpiry = DateTimeOffset.FromUnixTimeSeconds(long.Parse(newPayload["exp"])).UtcDateTime; localContext.TokenService.SetAccessToken(settings.TokenKeyGuid, newToken, newExpiry); return newToken; } private Dictionary<string, string> DecodeJwtPayload(string jwt) { var parts = jwt.Split('.'); var payload = parts[1].PadRight(parts[1].Length + (4 - parts[1].Length % 4) % 4, '='); var bytes = Convert.FromBase64String(payload); var json = Encoding.UTF8.GetString(bytes); return JsonConvert.DeserializeObject<Dictionary<string, string>>(json); } private string FetchTokenFromOAuth(SecureSettings settings) { // Simulated token fetch logic return "eyJhbGciOi..."; // JWT token } private void CallExternalService(string token, ITracingService tracingService) { tracingService.Trace("Calling external service with token..."); // Simulated API call } } 🧩 Wrapping It All Together By combining these patterns into the base class–child class structure, we get a plugin framework that is: ✅ Familiar and extensible ⚡️ Optimized for performance with token caching 🗣️ Final Thoughts These patterns weren’t invented in a vacuum—they were shaped by real customer needs and constraints. Whether you're modernizing legacy plugins or building new ones, I hope these ideas help you deliver more robust, scalable, and supportable solutions.LTRDisplay Control - End-to-End Implementation and Usage Guide
1. Executive Summary LTRDisplay is a Power Apps Component Framework (PCF) control for model‑driven apps that helps users browse Long Term Retention (LTR) data in a familiar grid‑and‑form experience. GitHub SourceCode The control is designed for archive‑first usage in Dataverse: Fetch retained records with a selected view clause Replay cached data without refetching Open row details inside the same control Review audit changes and related records Minimize retained query calls through user‑local caching and lazy loading This document provides: Purpose and business value Solution design and architecture Import and validation steps Full user manual Repository fork and customization workflow 2. Purpose of the Control 2.1 Problem Statement Retention data is valuable for: Investigation Support Compliance Historical analysis However, users often require: Fast browsing of retained records Predictable filtering and navigation Minimal load on retained query infrastructure A form‑like experience for details, audit, and related data 2.2 LTRDisplay Objectives LTRDisplay addresses these needs by: Surfacing retained records directly in a model‑driven form Reusing Dataverse views/forms metadata for familiarity Introducing cache‑first interaction patterns Supporting drill‑down across related records in one panel 3. Solution Design 3.1 Runtime Design Main runtime behavior: Archive‑focused mode by default Selected view drives retained fetch clause Grid renders from cached projection Related records load only on explicit user action Detail form and tabs render from metadata and selected row payload 3.2 Core Components PCF shell: LTRDisplayControl/index.ts App state orchestration: LTRDisplayControl/components/App.tsx Grid and local filtering: LTRDisplayControl/components/DynamicGrid.tsx Metadata‑driven detail form: LTRDisplayControl/components/DynamicForm.tsx Dataverse access layer: LTRDisplayControl/services/LtrService.ts View/Form XML parsing: LTRDisplayControl/utils/XmlParser.ts 3.3 Cache Model Per‑user browser cache stores: View datasets Entity record dictionary by record id Related datasets Forms metadata Relationship metadata This enables: Show Cached behavior without server refetch Faster row‑open and navigation experience Reduced retained query consumption 3.4 UX and Interaction Model Fetch Archive button: calls retained fetch and updates cache Show Cached button: reads cache and applies local filtering Column filter flyouts: local filtering against projected rows Detail tabs: Summary Record Data Audit History Related Form switcher: choose available main forms for selected entity Chrome toggle arrows: hide/show header and command bar behavior 3.5 Security Intent LTRDisplay Main Form is intended for System Administrator users Role‑based form visibility should restrict exposure to non‑admin users 4. Solution Packaging and Import 4.1 Distributed Artifacts Latest packaged solution files: solution/LTRDisplay_managed_latest.zip solution/LTRDisplay_unmanaged_latest.zip Unpacked inspection artifacts: exports/unpacked_managed exports/unpacked_unmanaged 4.2 Import in Power Platform (Recommended Managed Path) Open target environment in Maker Portal Go to Solutions Select Import solution Upload solution/LTRDisplay_managed_latest.zip Complete import and publish customizations 4.3 Post‑Import Validation Checklist Validate the following: LTRDisplay Main Form exists and is enabled SystemUser form maps to ltr_LTRDisplay.LTRDisplayControl System Administrator can open the form Non‑admin users do not get the admin‑targeted form Fetch Archive returns retained rows Show Cached replays cached rows Record Data, Audit History, and Related tabs operate as expected 5. User Manual – Walkthrough Step 1 – Open form with control visible The form opens with Explorer – LTR and action controls. Step 2 – Toggle form chrome for focus Use the arrow controls to hide/show header and command bar. Step 3 – Start retained fetch Click Fetch Archive. During loading, controls can be temporarily disabled. Step 4 – Review fetched grid data Rows appear in the grid after retained fetch completes. Step 5 – Apply local column filter Open a column filter, enter a value, and apply the filter. Step 6 – Open a row into detail context Select a grid row to open detail section and tabs. Step 7 – Use form switcher Open the detail form dropdown and choose alternate form layouts when available. Step 8 – Inspect Record Data tab Review key‑value field output. Step 9 – Inspect Audit History tab Review: Changed by, Changed on, Operation, Old and New value. Step 10 – Use Related tab Select relationship and click Load to fetch related rows lazily. 6. Fork and Customize the Repository 6.1 Fork and Clone Fork the repository in GitHub Clone your fork locally Create a feature branch for your changes 6.2 Local Build Setup From repository root: npm install npm run build 6.3 Typical Customization Areas Most teams customize: App‑level behavior and UX flow components/App.tsx Grid columns and filter behavior components/DynamicGrid.tsx Detail tabs and rendering components/DynamicForm.tsx Dataverse query strategy services/LtrService.ts Styling and branding css/LTRDisplayControl.css 6.4 Push Changes to Dataverse (Development Loop) Use your existing PAC workflow in the target environment. Typical sequence: npm run build pac pcf push --publisher-prefix ltr --incremental pac solution publish 6.5 Export and Repackage After validation in environment: Export managed and unmanaged solution zips Update: LTRDisplay_managed_latest.zip LTRDisplay_unmanaged_latest.zip If needed, unpack for review under: exports/unpacked_managed exports/unpacked_unmanaged 6.6 Recommended Contribution Workflow Keep changes scoped by feature branch Run build before each push Capture screenshots for changed UX behavior Update docs in docs folder together with code Submit PR with: Short validation checklist Test evidence 7. Operational Notes and Best Practices Use managed package for consumer installation Keep unmanaged package for internal customization scenarios Treat retained fetches as expensive Prefer cache replay when possible Keep related loading on‑demand to control query volume Preserve role‑based visibility for admin‑focused forms 8. Conclusion LTRDisplay provides a practical archive exploration interface for Dataverse model‑driven apps with a strong focus on: Usability Cache efficiency Operational control By combining: Managed distribution Clear import validation A straightforward customization model Teams can adopt it quickly and evolve it safely for enterprise needs.
Conditional Access for Canvas Apps with Entra
In today's Power Platform landscape, administrators have a tough task securing the ever-increasing inventory of Canvas Apps across their tenant. Canvas apps often connect to sensitive data, run on a variety of devices, and serve diverse groups of users. That is why Conditional Access has become one of the most powerful tools in an admin’s toolkit, giving you fine grained control over how, where, and under what conditions users can access your apps. In this post, I will walk through what Conditional Access means for canvas apps, how it empowers admins to maintain strong security without adding friction for legitimate users, and example steps to apply your own conditional access policies to an app with PowerShell. What Conditional Access Brings to Canvas Apps Conditional Access brings granular, app-level security controls from Microsoft Entra ID directly into Power Apps. Instead of applying blanket restrictions across the entire tenant, you can enforce requirements—like MFA, compliant devices, or trusted networks—only on the apps that need them. This lets you match security to the sensitivity of each individual app. Key Benefits for Admins Tailored Protection for Sensitive Apps Not every app requires strict controls. Conditional Access allows you to tighten security only for apps that handle sensitive or regulated data, without over restricting everything else. Control Access by Device Type Admins can easily block or allow specific device categories—like preventing mobile access to a high-risk app or requiring managed devices for apps that contain confidential information. Alignment With Zero Trust Conditional Access enforces identity, device, and session checks in real time, supporting a Zero Trust approach without adding unnecessary friction for legitimate users. Environment-Specific Flexibility You can apply stricter policies in production and lighter ones in development or testing, helping teams build efficiently while keeping sensitive environments locked down. A Stronger Security Model Conditional Access does not replace existing apps or data permissions—it complements them. App-level security roles control what users can do inside an app, while Conditional Access governs whether they can get into the app at all. Together, they create a much more robust security posture. How to enable conditional access for a Canvas App example In this example, I will detail steps to set up conditional access for a Canvas App to ensure tenant guest users are not able to access the app. Step 1: Create an Authentication Context in Entra ID Go to the Microsoft Entra Admin Center. Navigate to Protection → Conditional Access → Authentication context. Click + New authentication context. Name it (e.g., BlockGuests_PowerAppX) Enable Publish to apps Save and note the Authentication Context ID Step 2: Create a Conditional Access Policy Go to Conditional Access → Policies → + New policy. Name the policy (e.g., Block Guests from Power App X). Assignments: Users or workload identities: Include: Guest or external users Target resources: Choose Authentication context Select the one you created earlier Access controls: Grant: Select Block access Enable the policy and click Create. Step 3: Assign the Authentication Context to the Power App Use PowerShell to bind the Authentication Context to the specific Power App: Open PowerShell as Administrator. Connect to Power Apps Add-PowerAppsAccount Run the command to attach the context to your canvas app Set-AdminPowerAppConditionalAccessAuthenticationContextIds -EnvironmentName "<your-environment-name>" ` -AppName "<your-app-id>" ` -AuthenticationContextIds "<your-auth-context-id>" This binding tells Power Apps: “When this app opens, trigger the Conditional Access policy tied to this context.” Step 4: Test the Policy Try accessing the app as a guest user. You should see access blocked based on the Conditional Access policy. Wrap Up A Stronger Security Model Conditional Access does not replace existing apps or data permissions—it complements them. App-level security roles control what users can do inside an app, while Conditional Access governs whether they can get into the app at all. Together, they create a much more robust security posture. Bottom Line Conditional Access gives admins the flexibility to apply the right security to the right app. Whether you are enforcing MFA, restricting device types, or securing production environments, it helps you protect sensitive data without slowing down the organization. Documentation for further reading: Manage Power Apps - Power Platform | Microsoft Learn Demo from Power CAT: Conditional Access Policies for Canvas Apps - Power CAT Live
Microsoft Sentinel and Dataverse Integration
Integrating Microsoft Sentinel with Microsoft Dataverse brings advanced, unified security monitoring to your Power Platform environments. Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) that collects and correlates logs from across Azure, Microsoft 365, and more to detect and respond to threats in real time. By streaming Dataverse audit logs into Sentinel, organizations gain centralized visibility into Power Platform activity and can leverage Sentinel’s analytics and automation to rapidly detect suspicious behavior and enhance governance. Benefits of Connecting Dataverse to Sentinel Unified Visibility and Threat Detection: All Dataverse audit events (e.g. record access, changes, logins) are ingested into Sentinel, where they can be correlated with signals from identities, devices, and other applications. This holistic view enables detection of suspicious patterns that might be missed in isolation. For example, security analysts can spot anomalies like: mass data exports unusual access locations sudden policy changes in Dataverse operations Sentinel provides out-of-the-box analytics rules to flag many of these risky behaviors (such as a departing user downloading large datasets or deleting records) without requiring custom queries. 2. Faster Investigation and Response: With Dataverse logs in Sentinel, analysts can use Kusto Query Language (KQL) to quickly search and correlate Dataverse activity with other security logs (identity sign-ins, Office 365 events, etc.). This speeds up root-cause analysis during incidents. Moreover, Sentinel’s SOAR capabilities mean you can trigger automated playbooks in response to Dataverse threats. For instance, if Sentinel detects an anomalous privilege escalation in Dataverse, it could automatically disable the user’s account or alert an admin via Teams. This rapid, automated response helps contain threats immediately, reducing the time to mitigate incidents. 3) Improved Governance and Compliance: Integrating Dataverse with Sentinel strengthens oversight of Power Platform usage. All audit logs are stored in Sentinel’s scalable data lake, allowing long-term retention for compliance at a lower cost than storing in Dataverse. By correlating Dataverse activity with other enterprise logs, organizations can ensure that Power Platform apps adhere to security policies and can prove compliance. Prerequisites Before deploying the integration, ensure the following prerequisites are in place: Microsoft Sentinel workspace: Microsoft Sentinel enabled in the workspace: (See Here to Onboard to a Microsoft Sentinel Workspace) 2. You must have permission to create Data Collection Rules (DCR) and Data Collection Endpoints in that workspace. Roles and permissions in the Microsoft Sentinel platform | Microsoft Learn Data collection rules in Azure Monitor - Azure Monitor | Microsoft Learn Dataverse environment: 3. The Dataverse environment must be a production environment (Dataverse logging for Sentinel is only supported for production, not sandbox). 4. Your organization should be using Dynamics 365 Customer Engagement and/or Power Platform apps (since those rely on Dataverse). 5. Audit logging enabled: Auditing must be turned on for the Dataverse environment in the Power Platform admin settings (which also routes audit logs to Microsoft Purview). Setup With prerequisites met, follow these high-level steps to set up the Sentinel integration: Enable Dataverse Auditing (if not already enabled).In the Power Platform admin center, ensuretenant-level and environment-level auditing is on. Dataverse auditing is not enabled by default, so this is critical. You’ll also need to enable auditing on the entity (table) level for all relevant Dataverse tables. Microsoft provides a managed solution to simplify this: Import the Audit Settings solution: If your environment uses Dynamics 365 CE apps, import the solution from aka.ms/AuditSettings/Dynamics; otherwise use aka.ms/AuditSettings/DataverseOnly. This managed solution will turn on detailed auditing for all standard tables (entities) in Dataverse. For any custom tables, manually enable auditing in their settings (toggle on Auditing for the entity). In each entity’s settings, under Auditing, enable the options for “Single record auditing” and “Multiple record auditing” to capture detailed create/update/delete events. Then save and publish these changes. Enabling these ensures you capture granular audit logs needed for Sentinel. 2. Install the Sentinel Solution and Connect Data Sources. In the Azure Sentinel portal Azure Portal or the Security Admin Portal Defender Portal navigate to the Content hub (or in Microsoft Defender portal, go to Content hub for Sentinel) and install the “Microsoft Sentinel Solution for Microsoft Business Applications.” This deploys all the components (analytics rules, workbooks, connectors, etc.) for Power Platform integration. Once installed, go to Configuration > Data connectors in Sentinel. You will see new connectors available for: Microsoft Dataverse Microsoft Power Platform Admin Activity Microsoft Power Automate (A connector for Dynamics 365 Finance & Operations is also included for organizations using Dynamics F&O). Follow this link for more details on F&O connector: Connect Microsoft Dynamics 365 Finance and Operations to Microsoft Sentinel | Microsoft Learn For each relevant data connector (Dataverse, Power Platform Admin, Power Automate), open its page and select Connect. This step links your Dataverse environment’s audit stream to Sentinel via the Azure Monitor DCR infrastructure. After connecting, Sentinel will start listening for the audit logs from Purview. ValidateData Ingestion. With auditing enabled and connectors in place, perform some sample activities in your Dataverse environment to generate logs (for example, create or update a row in a Dataverse table, change a Power Platform environment setting, run a Power Automate flow). In general, Dataverse and Power Automate activity logs should begin flowing into Sentinel within a few minutes, whereas Power Platform admin logs (e.g. environment or D365 admin actions) may take up to an hour for the first time. Be patient and then verify ingestion by querying the logs in Sentinel. You can run KQL queries in the Logs blade of the Sentinel Azure portal (or the Hunting section of Defender portal) to confirm data is arriving. For example, run a query on the PowerPlatformAdminActivity table to see if recent records exist. After a successful setup, Microsoft Sentinel will be populating three main Log Analytics tables with your Dataverse-related logs (as listed below): Log Analytics Table Data Collected PowerPlatformAdminActivity Power Platform administrative logs (e.g. environment settings changes, user role assignments) PowerAutomateActivity Power Automate (Flow) activity logs (creation, runs, etc.) DataverseActivity Dataverse and model-driven app business data activity logs (create, update, delete events on records, etc.) These tables contain the audit data that Sentinel will use for analysis. For instance, an update to a row in a Dataverse table will generate an event in the DataverseActivity table, whereas an administrative action like changing a Data Loss Prevention (DLP) policy or adding a user to an environment appears in PowerPlatformAdminActivity. Analytics and Threat Detection Capabilities Once the data is flowing, you can leverage Microsoft Sentinel’s powerful analytics and automation on your Dataverse logs. The Microsoft Business Apps Sentinel solution you installed comes with prebuilt analytics rules tailored to Dataverse and Power Platform scenarios. These rules will automatically generate incidents for suspicious patterns, such as: Mass record downloads or deletions (which could indicate a potential data theft or misuse) Anomalous access, like a user accessing Dataverse from an unusual location or at an odd time Privilege escalations or policy changes, e.g. a user suddenly gaining a system admin role, or a DLP policy being turned off. Security teams can also create custom detection rules using KQL to address organization-specific threats. All the Dataverse audit logs in Sentinel are fully queryable – for example, you could write a query to find when a particular record was modified and by whom, or to detect an unusual spike in Power Automate flow failures. These queries can be turned into new alert rules as needed. Sentinel provides interactive workbooks and a hunting interface to help visualize and drill into this data for proactive threat hunting. In addition to detection, Sentinel enables automated response for Power Platform incidents. Using Playbooks (Logic Apps), you might automate actions like disabling a user’s Power Platform account, alerting the IT team via Microsoft Teams, or creating a ticket in ServiceNow whenever a high-severity Dataverse incident is detected. For example, if multiple deletion events are detected in a short span on a sensitive table, a playbook could immediately notify a security channel and suspend the user's access pending investigation. This kind of end-to-end automation greatly improves your security posture by reducing response times and ensuring consistent actions. In summary, connecting Dataverse auditing to Microsoft Sentinel equips organizations with a unified view of business application activity and the advanced tools to detect, investigate, and respond to potential security issues in their Power Platform environments. It marries the rich audit data from Dataverse with Sentinel’s powerful SIEM capabilities – enabling proactive monitoring of user actions, quick identification of anomalies, and automated defense measures to protect your low-code applications. With the integration set up, Power Platform admins and security analysts can rest easier knowing that any unusual or malicious activity in Dataverse will light up on the Sentinel radar and be handled swiftly. For detailed step-by-step guidance, refer to Microsoft’s documentation on connecting Power Platform (Dataverse) to Sentinel and Connect Microsoft Dynamics 365 Finance and Operations to Microsoft Sentinel | Microsoft Learn These resources provide deeper instructions and additional tips for a successful integration.In-App Notification PCF Control
Overview A robust Power Apps Component Framework (PCF) control for Dataverse, designed to deliver, display, and manage in-app notifications. This control supports secure environment variable lookup, publisher-agnostic logic, recipient resolution, and integrates with Microsoft Graph for advanced scenarios. It is built for easy adoption by developers and customers. Testing Status: This control has been tested for minimum positive flow scenarios. Comprehensive testing for edge cases, error handling, and production readiness is recommended before deployment. For more information about in-app notifications in Dataverse, see Microsoft Docs: Send in-app notifications within model-driven apps. Build & Run npm install npm run build Features Notification Delivery: Send notifications to users or groups in Dataverse. Recipient Resolution: Fetch and display recipient names using systemuser IDs. Environment Variable Lookup: Secure, publisher-agnostic configuration. Microsoft Graph Integration: Authenticate and fetch data from Microsoft Graph using MSAL.js. Robust UI: Modern, responsive React components with Fluent UI styling. Error Handling: Graceful fallback for missing recipients and robust client-side logic. Project Structure NotificationControl/ components/ NotificationDetails.tsx # Displays notification details and recipient info NotificationForm.tsx # Main form for creating and sending notifications NotificationList.tsx # Lists all notifications and handles navigation NotificationForm.css # Styles for the notification form NotificationList.css # Styles for the notification list context/ NotificationContext.tsx # React context for notification state hooks/ useNotifications.ts # Custom hook for notification logic utils/ api.ts # Core notification logic, environment variable lookup, Graph API integration auth.ts # Authentication helpers for MSAL.js ControlManifest.Input.xml # PCF control manifest (input) ControlManifest.xml # PCF control manifest index.ts # Entry point for the control Component Details & Usage NotificationList.tsx Purpose: Displays a list of notifications and allows navigation to detail view. Notifications are grouped by title and body for efficiency. Props: notifications: Array of notification objects. onSelect: Handler to select a notification for detail view. Key Features: Grouping: Notifications are grouped by title and body because the same notification is sent separately to each recipient in Dataverse. This prevents duplicate entries in the list view. Lazy Loading: Recipients are loaded on-demand (lazy loaded) when you click to view details, reducing initial load time and improving performance. Date Filtering: Only notifications from the last 7-14 days are loaded to keep the list manageable and avoid costly aggregation queries on large datasets. Adoption: Use to provide users with an overview of all notifications. Passes context and props to child components. Sent notifications grouped by title and body, showing count and recipient access. NotificationDetails.tsx Purpose: Displays the details of a notification, including title, body, icon, type, and recipient information. Props: notification: The notification object to display. showSystemUsers: Whether to show recipient info. onBack: Handler to return to the notification list. context: Dataverse context for API calls. Key Functions: fetchNames: Fetches recipient names from Dataverse using systemuser IDs. Handles missing recipients gracefully by showing "No recipient assigned". Adoption: Use in detail view to show notification info and recipient names. Handles all edge cases for missing or undefined recipients. Detail view with graceful fallback for missing recipients. NotificationForm.tsx Purpose: Main form for creating and sending notifications. Centralizes environment variable and authentication logic. Props: context: Dataverse context for environment variable lookup and authentication. Key Functions: Handles user input, MSAL authentication, and notification submission. Features: Multiple recipient selection options: System Users, Teams, Queues, and Outlook DLs Required fields: Title and Body Optional settings: Icon Type (Info, Success, Error, Warning) and Notification Type (Toast, Banner) Adoption: Use as the entry point for users to create and send notifications. Integrates with Microsoft Graph for advanced scenarios. Comprehensive form with multiple recipient selection options: System Users, Teams, Queues, and Outlook DLs. NotificationContext.tsx Purpose: Provides global notification state and actions to components via React context. Adoption: Use to share notification state and actions across components. useNotifications.ts Purpose: Custom React hook for fetching, sending, and managing notifications. Adoption: Use in components to access notification logic and state. api.ts Purpose: Contains core logic for notification delivery, environment variable lookup, recipient resolution, and Microsoft Graph API integration. Key Functions: getDLMemberObjectIds, getSystemUserIdsByObjectIds, getSystemUserNamesByIds: Utility functions for recipient resolution. Adoption: Use for all backend logic and API calls related to notifications. auth.ts Purpose: Handles authentication logic using MSAL.js for Microsoft Graph API access. Adoption: Use to authenticate users and obtain tokens for Graph API calls. How to Adopt This Control Import the control into your Dataverse environment. Configure environment variables for publisher-agnostic setup. Grant users read privileges on the appnotifications entity. Users receiving in-app notifications must have read privilege on the appnotifications table in Dataverse to view their notifications. Use NotificationForm to create and send notifications. Display notifications using NotificationList and NotificationDetails. Integrate with Microsoft Graph by configuring Azure AD app registration and MSAL.js. Customize styles using the provided CSS files. Prerequisites: Environment Variables & Attaching the Control 1. Environment Variables Setup Important: This control uses Dataverse environment variables (not local .env files) to store configuration values like Azure AD app registration details for Microsoft Graph integration. Required Environment Variables: You must create the following environment variables in your Dataverse organization: InAppNotif_App_Tenant_Id - Your Azure AD Tenant ID InAppNotif_App_Client_Id - Your Azure AD App Registration Client ID (for Microsoft Graph/MSAL authentication) How to Create Environment Variables in Dataverse: Go to Power Apps Maker Portal (make.powerapps.com) Select Solutions from the left navigation Open your solution (or create a new one) Click New > More > Environment variable Create each variable: Display Name: InAppNotif App Tenant Id (or similar) Name: InAppNotif_App_Tenant_Id Data Type: Text Default Value: Your Azure AD Tenant ID Repeat for InAppNotif_App_Client_Id How the Control Uses These Variables: The control reads these environment variables at runtime using the Dataverse WebAPI: // Example from api.ts const clientId = await getEnvironmentVariable("InAppNotif_App_Client_Id", context); const tenantId = await getEnvironmentVariable("InAppNotif_App_Tenant_Id", context); This approach makes the control publisher-agnostic and easy to configure across different environments without modifying code. 2. Attaching the Control to a Form This PCF control can be attached to any field on any form in Dataverse. The control supports the following field types: Single Line of Text Email Phone URL Multiple Lines of Text Whole Number Important: The field value itself is not used by the control—it only serves as a placeholder for the control's UI. You can place this control on any entity (User, Account, Contact, custom entities, etc.) based on your requirements. Steps: Navigate to the Form Editor Go to Power Apps Maker Portal (make.powerapps.com) Select Tables from the left navigation Choose your desired table (e.g., User, Account, Contact) Click on Forms tab Select and edit the form where you want to add notifications Add or Select a Field Find an existing field that matches one of the supported types (Text, Email, Phone, URL, Multiple Lines, Whole Number) Or add a new field to the form if needed Click on the field to select it Add the Custom Control With the field selected, click + Component in the right panel Or right-click the field and select Properties > Components tab Click + Component Search for and select NotificationControl The control will appear in the Components list Configure Control Properties Label: Set a custom label (e.g., "Notifications") Hide label: Check this to hide the field label (recommended for cleaner UI) Form field width: Set to desired column width (default: 1 column) Show component on: Select platforms (Web, Mobile, Tablet) Click Done Set as Primary Control (Optional) In the Components section, you'll see both the default field control and NotificationControl You can make NotificationControl the primary control for better visibility Or keep both and configure display preferences Save and Publish Click Save to save your changes Click Publish to make the control available to users The control will now appear on the form when users access it Example: NotificationControl configured on Primary Email field of User form Result: The control will appear on the form, showing all in-app notifications for the current environment Users can view, create, and manage notifications directly from any form where the control is placed The control displays with a "New Notification" button and list of existing notifications grouped by title/body Prerequisites: Outlook DL Selection & Graph API Access 1. Outlook Distribution List (DL) Selection To enable users to select Outlook Distribution Lists (DLs) for notifications, your control integrates with Microsoft Graph API. This requires: Azure AD app registration with delegated permissions to read DLs and users. Environment variable(s) to store the Azure AD Client ID and other config. Steps: Register an app in Azure AD (portal.azure.com > Azure Active Directory > App registrations). Add delegated permissions for Group.Read.All, User.Read, and any other required Graph scopes. Store the Client ID and other config in Dataverse environment variables. Configure your control to use these variables for Graph API calls. 2. App Registration & Graph API Access The app registration must allow access to Microsoft Graph for reading users and groups. Redirect URI should be set for SPA (Single Page Application) and implicit grant enabled. The control uses MSAL.js to authenticate and acquire tokens for Graph API. Security Note: By default, the control stores the authentication token in the browser (local/session storage) for convenience and seamless user experience. If customers want to avoid storing tokens in the browser: They can disable persistent authentication or use a different MSAL configuration. This may require users to re-authenticate more frequently and could impact usability. Document this option in your deployment guide and provide configuration instructions. Example MSAL config: const msalConfig = { auth: { clientId: clientIdFromEnvVar, authority: "https://login.microsoftonline.com/common", redirectUri: window.location.origin }, cache: { cacheLocation: "sessionStorage", // or "localStorage" storeAuthStateInCookie: false } }; Redirect URI Requirement for MSAL Silent Authentication Why You Need a Redirect URI For MSAL.js to perform silent authentication (acquire tokens without user interaction), your Azure AD app registration must include a valid redirect URI. In Dataverse/Power Apps, this is often set to an empty HTML web resource. Purpose: The redirect URI is where MSAL will redirect the browser after authentication. For silent authentication, MSAL uses an iframe and the redirect URI must be a valid, accessible page in your environment. An empty HTML web resource is commonly used because it loads quickly and does not display content. How to Set Up Create an empty HTML web resource in Dataverse: Go to Power Apps > Solutions > Add > Web Resource. Name it (e.g., msal-redirect.html). Content can be just:<html><head></head><body></body></html> Save and publish. Add the web resource URL as a redirect URI in Azure AD app registration: Go to Azure Portal > Azure Active Directory > App registrations > Your app. Under Authentication, add the web resource URL (e.g., https://<org>.crm.dynamics.com/WebResources/msal-redirect.html) as a redirect URI for SPA. Enable Access tokens and ID tokens under Implicit grant. Important: When adding your web resource redirect URI as a SPA in Azure AD app registration, ensure you enable both Access token and ID token under Implicit grant. This allows MSAL.js to acquire tokens for authentication and API access, enabling seamless user experience and secure integration with Microsoft Graph. Example Redirect URI: https://yourorg.crm.dynamics.com/WebResources/msal-redirect.html Why This Matters Without a valid redirect URI, MSAL cannot complete silent authentication and users may be prompted to sign in more often. The empty HTML web resource acts as a safe landing page for token acquisition. Using Dataverse Teams for In-App Notifications If your organization configures on-floor teams as Dataverse Teams (with members assigned in Dataverse), supervisors can leverage this feature to send targeted in-app notifications to their team members. How It Works Dataverse Team: A group entity in Dataverse that can have multiple users as members. Teams can represent departments, on-floor groups, or any logical unit. Supervisor Use Case: If you are a supervisor and your team is set up as a Dataverse Team, you can select the team in the notification form and send in-app notifications to all its members at once. Benefits Targeted Communication: Easily notify all team members about important updates, tasks, or alerts. Efficient Workflow: No need to select individual users; simply select the team and send the notification. Integration: The PCF control fetches team members from Dataverse and ensures notifications are delivered to each member. Example Scenario A supervisor wants to notify their on-floor team about a shift change. The team is configured as a Dataverse Team. The supervisor selects the team in the notification form and sends the message. All team members receive the notification instantly in their Dataverse environment. How to Set Up Ensure your teams are created and configured in Dataverse (Power Apps > Teams). Assign users as members to each team. Use the notification form in the PCF control to select a team and send notifications. This approach streamlines communication and ensures all relevant users are informed efficiently. For more details, see Microsoft Docs: Manage teams in Dataverse. Using Queue Selection for Workstream Notifications If your organization uses queues and workstreams (common in Customer Service or Omnichannel scenarios), you can leverage queue selection to send in-app notifications to all agents associated with a specific workstream. How It Works Queue: A Dataverse entity that holds work items and is associated with agents who can work on those items. Workstream: A collection of queues and routing rules that define how work is distributed to agents. Agent Use Case: Supervisors or admins can select a queue in the notification form to send in-app notifications to all agents assigned to that queue's workstream. Benefits Targeted Communication: Notify all agents working on a specific queue or workstream about important updates, new assignments, or urgent issues. Efficient Workflow: No need to manually identify and select agents; simply select the queue and the control will resolve all associated agents. Integration: The PCF control fetches queue members from Dataverse and ensures notifications are delivered to each agent. Example Scenario A supervisor wants to notify all agents working on the "Support Queue" about a critical system update. The supervisor selects the queue in the notification form and sends the message. All agents associated with that queue's workstream receive the notification instantly. How to Set Up Ensure your queues and workstreams are configured in Dataverse (Power Apps > Queues). Assign agents to queues or workstreams. Use the notification form in the PCF control to select a queue and send notifications to all associated agents. This approach is especially useful for Customer Service and Omnichannel environments where agents are organized by workstreams. For more details, see Microsoft Docs: Manage queues in Dataverse. For more details, see the Microsoft Docs: Use environment variables in Dataverse, Add PCF controls to forms, Microsoft Docs: Register an app with Azure AD, and MSAL.js configuration options. Developer Notes All components are documented with JSDoc comments for easy understanding. Error handling and fallback logic are implemented for robust user experience. The codebase is modular and easy to extend for new notification types or integrations. Contributing Fork the repository and create a pull request for improvements or bug fixes. Please document new components and functions using JSDoc comments and update the README as needed. Testing & Production Readiness Current Testing Status: This control has been tested for minimum positive flow scenarios only. Before Production Deployment: Perform comprehensive testing including edge cases, error scenarios, and negative flows Conduct security audits and vulnerability assessments Test with your organization's specific Dataverse configuration and data Validate performance under expected load conditions Ensure compliance with your organization's governance and security policies License MIT Disclaimer USE AT YOUR OWN RISK This control is provided as-is without any warranties, express or implied. Neither the author nor Microsoft Corporation are responsible for any issues, damages, or losses arising from the use, deployment, or adaptation of this control. Important: This control has been tested for minimum positive flow scenarios only Organizations must conduct their own thorough review and testing before deployment Ensure the control meets your organization's security, compliance, and design standards No support or maintenance guarantees are provided Responsibility: By using this control, you acknowledge that you have reviewed the code, tested it in your environment, and accept full responsibility for its deployment and operation within your organization.Seamless blend of ILogger with ITracingService inside D365 CE Plugins
👋 Introduction This document introduces a practical approach for integrating Application Insights logging into Dynamics 365 plugins using the ILogger interface alongside the existing ITracingService. The key advantage of this method is its minimal impact on the existing codebase, allowing developers to adopt enhanced logging capabilities without the need to refactor or modify each plugin individually. By wrapping the tracing logic, this pattern promotes maintainability and simplifies the transition to modern observability practices with a single, centralized change. 🧱 The Classic Plugin Base Pattern Most customers already use a base class pattern for plugins. This pattern wraps the IPlugin interface and provides a LocalPluginContext object that encapsulates services like IOrganizationService, ITracingService, and IPluginExecutionContext. ✅ Benefits: Reduces boilerplate Encourages separation of concerns Makes plugins easier to test and maintain 🧩 Base Class with try-catch in Execute public abstract class PluginBase : IPlugin { protected internal class LocalPluginContext { public IOrganizationService OrganizationService { get; } public ITracingService TracingService { get; } public IPluginExecutionContext PluginExecutionContext { get; } public LocalPluginContext(IServiceProvider serviceProvider) { PluginExecutionContext = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); TracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); OrganizationService = ((IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory))) .CreateOrganizationService(PluginExecutionContext.UserId); } } public void Execute(IServiceProvider serviceProvider) { try { var localContext = new LocalPluginContext(serviceProvider); localContext.TracingService.Trace("Plugin execution started."); ExecutePlugin(localContext); localContext.TracingService.Trace("Plugin execution completed."); } catch (Exception ex) { var tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); tracingService.Trace($"Unhandled exception: {ex}"); throw new InvalidPluginExecutionException("An error occurred in the plugin.", ex); } } protected abstract void ExecutePlugin(LocalPluginContext localContext); } 📈 Seamless Application Insights Logging with a Tracing Adapter 💡 The Problem Many customers want to adopt Application Insights for plugin telemetry—but hesitate due to the need to refactor hundreds of TracingService.Trace(...) calls across their plugin codebase. 💡 The Innovation The following decorator pattern wraps ITracingService and forwards trace messages to both the original tracing service and an ILogger implementation (e.g., Application Insights). The only change required is in the base class constructor—no changes to existing trace calls. 🧩 Tracing Adapter public class LoggerTracingServiceDecorator : ITracingService { private readonly ITracingService _tracingService; private readonly ILogger _logger; public LoggerTracingServiceDecorator(ITracingService tracingService, ILogger logger) { _tracingService = tracingService; _logger = logger; } public void Trace(string format, params object[] args) { _tracingService.Trace(format, args); _logger?.LogInformation(format, args); } } 🧩 Updated Base Class Constructor public LocalPluginContext(IServiceProvider serviceProvider) { PluginExecutionContext = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); var standardTracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); var logger = (ILogger)serviceProvider.GetService(typeof(ILogger)); TracingService = new LoggerTracingServiceDecorator(standardTracingService, logger); OrganizationService = ((IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory))) .CreateOrganizationService(PluginExecutionContext.UserId); } This enables all trace calls to be logged both to Plugin Trace Logs and Application Insights. AppInsights Traces allows for easier troubleshooting using Kusto Query Language and enables alerting based on custom trace messages. 🧩 Using ILogger inside a plugin without base class This approach is exactly the same as implemented in plugins with a base class. However, in this case, we make the wrapping assignment once at the beginning of each plugin. This is far better compared to modifying every line that uses tracingService.Trace. public class ExistingPlugin : IPlugin { public void Execute(IServiceProvider serviceProvider) { var originalTracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); var logger = (ILogger)serviceProvider.GetService(typeof(ILogger)); // Wrap the original tracing service with the decorator var tracingService = new LoggerTracingServiceDecorator(originalTracingService, logger); tracingService.Trace("Plugin execution started."); try { // Existing plugin logic tracingService.Trace("Processing business logic..."); } catch (Exception ex) { tracingService.Trace($"Exception occurred: {ex}"); throw; } tracingService.Trace("Plugin execution completed."); } } 📣 Final Thoughts Logging with both ITracingService and ILogger inside LoggerTracingServiceDecorator will double the chance of WorkerCommunication, as it is usually a symptom of large amount text(Strings) tracing from loop constructs inside custom plugin code, hence it is good idea to stick to ILogger alone inside your decorator Trace method.
When Your CRM Plays Hide-and-Seek: The Mystery of Missing Columns in Dynamics 365
What Happened? Personal views across multiple organizations started showing empty columns, even though the data was there. For businesses that rely on these views for daily decisions, this isn’t a normal glitch—the end users can easily assume that “no data” in the view means no data in the record and make decisions based on an incomplete picture of customer information. The Detective Work Our investigation uncovered the culprit: a mismatch between two behind-the-scenes players—View XML and Fetch XML. Think of them as the blueprint and the builder. When they don’t talk to each other properly, your view looks fine but can’t fetch the data it needs. Why It Matters This isn’t just a tech hiccup—it’s a reminder of how small cracks in system design can ripple into big business headaches. It also highlights the need for smarter automation and better error detection in enterprise platforms. The Fix (and the Frustration) The good news? A manual fix was quickly identified over a year ago. The bad news? It was manual. And many impacted users didn’t even know that their views were bad. We needed a better solution and now, we have one. Starting in October 2025, Microsoft rolled out a behind the scenes fix option. Once it’s turned on, any time a user opens a corrupted view, that view will be automatically updated to display the correct data. If the user has permission to edit the view, the updates will be saved so that the view will be permanently fixed. But there’s still a catch. Microsoft doesn’t want to enable a process that makes data changes (in this case, the data is the view definition) without your company’s permission. If your organization is running into this issue, here’s a quick test to assure that the new Microsoft fix will work for you: Identify views that you know are not rendering properly and that you will be able to access If you create a copy of a view that is corrupted, the copy will also have the corruption, so you can create additional views to test In your browser URL bar, append the following to the end of your Dynamics URL: &flags=FCB.DataSetViewFixMissingFetchColumns=true This will enables a “feature flag” that fixes the views issue, but only for the user that added the flag to the URL and only until their session expires. Other users will not see the update. If your URL looks like this: https://org7909d641.crm.dynamics.com/main.aspx?appid=12345678-1234-1234-1234-123456789012 … make it look like this and hit enter https://org7909d641.crm.dynamics.com/main.aspx?appid=12345678-1234-1234-1234-123456789012&flags=FCB.DataSetViewFixMissingFetchColumns=true Wait for Dynamics to reload Test opening the corrupted views. You’ll see that they’re magically working as expected When you are satisfied that this is working for you as desired, open a case with Microsoft Support and request that your organization be enabled for the DataSetViewFixMissingFetchColumns FCB. This will enable the fix for all users across your Dynamics organization Takeaway: If your CRM starts acting like a magician hiding data, don’t panic. The data is still there—you just need to coax it back with the right fix. And now there’s an option to make sure that this issues goes away for good.Demystifying SessionTrackingId and Request Correlation in D365 CE Integrations
Introduction As a Cloud Solution Architect working with Dynamics 365 Customer Engagement (D365 CE) customers, I often see organizations building high-volume integrations using the ServiceClient SDK for .NET Core (or CrmServiceClient for classic .NET Framework). While these SDKs make it easy to connect and interact with Dataverse, tracking and diagnosing issues—especially in production—can be challenging. One of the least-known but most powerful features for support and diagnostics is the SessionTrackingId property on ServiceClient. In this post, I’ll explain what it is, how to use it, and why it’s invaluable for working with Microsoft support and troubleshooting performance issues. The Problem: Diagnosing Integration Performance Many customers log the time before and after each Dataverse call, and if they see high latency, they often suspect the Dataverse service itself. However, in large-scale, high-volume integrations, the real culprit is frequently client-side resource contention or SNAT port exhaustion. This can lead to slow connection establishment, WCF binding timeouts, and misleadingly high client-side timings—even when the server-side execution is fast. The Solution: SessionTrackingId and Request Correlation With ServiceClient, you cannot manually set HTTP headers. You rely on the SessionTrackingId property, which internally maps to the x-ms-client-session-id header. Microsoft support can use this ID to trace your request end-to-end, from your client to the Dataverse backend. When using HttpClient, you can achieve similar tracking by utilizing the User-Agent HTTP header to append a GUID, which helps Microsoft support correlate requests in telemetry for diagnostics and troubleshooting. Sample: Using SessionTrackingId and Logging Request Timing using Microsoft.PowerPlatform.Dataverse.Client; using Microsoft.Extensions.Configuration; using System; using System.IO; using System.Diagnostics; using Microsoft.Crm.Sdk.Messages; namespace D365UserAgentDemo { class Program { static void Main(string[] args) { var config = new ConfigurationBuilder() .SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json", optional: false) .Build(); var d365Section = config.GetSection("D365"); string appId = d365Section["AppId"]; string clientSecret = d365Section["ClientSecret"]; string orgUrl = d365Section["OrgUrl"]; string tenantId = d365Section["TenantId"]; string connectionString = $"AuthType=ClientSecret;Url={orgUrl};ClientId={appId};ClientSecret={clientSecret};TenantId={tenantId};"; // 1. Call with ServiceClient var sessionTrackingId1 = Guid.NewGuid(); Console.WriteLine($"\n[ServiceClient] Using SessionTrackingId: {sessionTrackingId1}"); string? accessToken = null; using (var svc = new ServiceClient(connectionString)) { svc.SessionTrackingId = sessionTrackingId1; try { var sw = Stopwatch.StartNew(); var response = svc.Execute(new WhoAmIRequest()); sw.Stop(); var userId = ((WhoAmIResponse)response).UserId; Console.WriteLine($"[ServiceClient] WhoAmI UserId: {userId}"); Console.WriteLine($"[ServiceClient] Time taken: {sw.ElapsedMilliseconds} ms"); Console.WriteLine($"[ServiceClient] TrackingId: {sessionTrackingId1}"); accessToken = svc.CurrentAccessToken; } catch (Exception ex) { Console.WriteLine($"[ServiceClient] Error: {ex.Message}"); } } // 2. Call with HttpClient var trackingId2 = Guid.NewGuid(); Console.WriteLine($"\n[HttpClient] Using User-Agent with embedded tracking ID: {trackingId2}"); if (!string.IsNullOrWhiteSpace(accessToken)) { using (var httpClient = new System.Net.Http.HttpClient()) { httpClient.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", accessToken); httpClient.DefaultRequestHeaders.UserAgent.Clear(); httpClient.DefaultRequestHeaders.UserAgent.ParseAdd($"D365UserAgentDemo/{trackingId2}"); httpClient.DefaultRequestHeaders.Remove("x-ms-client-request-id"); httpClient.DefaultRequestHeaders.Add("x-ms-client-request-id", trackingId2.ToString()); var apiBase = orgUrl.TrimEnd('/'); var apiUrl = $"{apiBase}/api/data/v9.2/WhoAmI"; try { var sw = Stopwatch.StartNew(); var httpResponse = httpClient.GetAsync(apiUrl).GetAwaiter().GetResult(); sw.Stop(); var content = httpResponse.Content.ReadAsStringAsync().GetAwaiter().GetResult(); Console.WriteLine($"[HttpClient] WhoAmI response: {content}"); Console.WriteLine($"[HttpClient] Time taken: {sw.ElapsedMilliseconds} ms"); Console.WriteLine($"[HttpClient] TrackingId (User-Agent): {trackingId2}"); } catch (Exception ex) { Console.WriteLine($"[HttpClient] Error: {ex.Message}"); } } } else { Console.WriteLine("No access token available from ServiceClient for HttpClient call."); } } } } Why This Matters Supportability: When you open a support ticket, provide the SessionTrackingId (for SDK). Microsoft support can trace your request through the entire stack. Root Cause Analysis: If you see high client-side latency, but Microsoft support shows fast server-side execution for your tracking ID, the issue is likely on the client (resource contention, SNAT exhaustion, etc.). Bonus: Classic .NET Framework If you’re using classic .NET Framework, use CrmServiceClient instead. The pattern is similar, and the property is also called SessionTrackingId. Conclusion The SessionTrackingId and embedded tracking IDs in User-Agent headers are powerful but underutilized features for D365 CE integrations. They enable precise request tracking, better support experiences, and faster root cause analysis. Although SessionTrackingId is documented as a session-level identifier, in practice it is best used to track individual requests—especially when diagnosing performance issues. Since ServiceClient does not expose a separate property for request-level correlation, assigning a unique SessionTrackingId per request is the most effective approach. Takeaway When client-side telemetry shows significantly higher latency than Power Platform telemetry, it’s a strong indicator that your integration needs horizontal scaling. Logging request-level timing with a unique tracking ID helps pinpoint these bottlenecks and guides you toward the right architectural decisions.
