Why do some Dynamics 365 users experience performance issues while others continue working normally?

This was one of the most interesting production issues I investigated. The original post was accidentally removed, so I'm bringing it back.

Same environment. Very different response times.

Some requests took over 4 seconds. Others completed in around 200ms. No platform-wide outage, Infrastructure appeared healthy. So what was happening?

One factor that stood out during my investigation was Cookie Affinity (Server Affinity).

In a load-balanced environment, cookie affinity can keep a clients subsequent requests routed to the same front-end server.

Why does this matter?

Imagine a high-volume integration sending thousands of requests. If requests remain associated with one server, that server may handle a disproportionate share of the traffic while other instances have more capacity available. Under the right conditions, this can contribute to uneven performance.

That's the interesting part: the overall platform can appear healthy while a particular workload experiences a bottleneck.

Microsoft documents the role of affinity in Dataverse and provides guidance for custom .NET clients processing parallel requests. Disabling affinity can be worth evaluating for suitable integration workloads, but it isn't a universal fix and browser-based clients always have server affinity enabled.

The lesson I took away: performance isn't just about how much capacity a platform has. How requests reach and use that capacity matters too. When investigating slow Dataverse integrations, cookie affinity is one factor worth understanding alongside concurrency, throttling and request patterns.

#Dynamics365 #Dataverse #PowerPlatform #PerformanceEngineering #Azure #TechnicalArchitecture

Enhanced Full Case form vs Custom Forms in D365 Customer Service

 Balancing Standardization and Flexibility in D365 Case Management — Why Enhanced Case Forms Should Be Your Default ?

In D365 Customer Service, the Case table can be surfaced to agents either via Microsoft’s Enhanced Case Form (the modern, multisession experience in Customer Service Workspace) or via custom forms you build in the Power Apps maker. Choosing the right default is a governance decision with direct impact on agent productivity, platform stability.

Over the past several months, I’ve been doing extensive research on D365 case management — analyzing what truly works best, diving deep into MS Docs, and reviewing implementation experiences — and while teams may ask for metrics or proof, Microsoft’s own statistics, recommendations, and field learnings consistently show that the Enhanced Full Case Form improves performance, reduces agent friction, and addresses many of the challenges organizations face

What the Enhanced Case Form gives you  

1. A multisession‑first UX designed for agents to work multiple cases in parallel with Quick Create and Full Case experiences.   

2. Preconfigured components such as Timeline, Customer 360, and Recent records that surface customer context without heavy custom wiring.   

3. A lower maintenance footprint because Microsoft evolves the experience and you enable it via admin toggles in the Customer Service admin center. 

What custom forms let you do  

1. Add bespoke UI elements: multiple custom tabs, PCF controls, web resources, and specialized subgrids for domain‑specific workflows.   

2. Implement business rules, JavaScript, and integrations that reflect unique KPIs or compliance needs.

Technical tradeoffs and decision criteria  

●Multisession behavior — Enhanced forms are built for session management; custom forms must be validated to behave correctly in tabbed/multisession contexts.

●Performance — Heavy subgrids, complex FetchXML, synchronous JS, and many PCF controls increase load time. If you need custom subgrids, optimize views, add server‑side filtering, and index lookup columns.

●Maintainability — Microsoft’s enhanced form reduces upgrade risk; custom forms require regression testing on platform updates and when enabling new Workspace features.   

Governance recommendation  

1. Default to Enhanced Case Form for all standard support queues to ensure consistent agent experience and lower admin overhead.   

2. Allow custom forms only via a formal exception process that requires: business justification, performance impact assessment, test plan, and a rollback strategy.   

3. Enforce performance guardrails: limit visible subgrids, prefer server‑side filtering, use PCF controls judiciously, and require indexing for frequently filtered columns. 

Agents are the front line of customer experience. Standardizing on an optimized, multisession form reduces cognitive load & speeds case resolution. Customization still has its place — but it must be governed, measured, and justified.#Dynamics365

Event-Driven Architecture in CRM Platforms: Scaling Beyond Forms and Subgrids

 Event-Driven Architecture in CRM Platforms: Scaling Beyond Forms and Subgrids

In enterprise CRM systems, performance bottlenecks often emerge not from the database itself, but from how events are handled across forms, subgrids, and side panes. As organizations scale, synchronous event handling becomes a silent killer—locking threads, consuming memory, and degrading user experience.  

Why Event-Driven Architecture Matters

Traditional request-response models work fine for small workloads, but in CRM platforms with thousands of concurrent sessions, they quickly collapse. Event-driven architecture (EDA) decouples producers and consumers, allowing:

- Asynchronous processing of CIF pub/sub events.  

- Memory cleanup through standardized handlers.  

- Scalable telemetry that tracks event flow without blocking user actions.  

Technical Patterns for CRM Stability

- Indexed Columns for Subgrids  

  Always validate that subgrid queries hit indexed columns. Without this, even optimized forms will degrade under load.  

Pub/Sub Standardization  

  Define a single event bus for CIF side panes. This prevents memory leaks caused by multiple listeners and ensures predictable cleanup.  

Telemetry-Driven Validation  

  Use KQL dashboards to monitor event throughput. Look for anomalies in session memory usage and CPU spikes tied to specific handlers.  

Governance cards

  Operationalize these patterns with visual checklists. For example:  

  - Is the subgrid query indexed?  

  - Are event listeners deregistered on unload?  

  - Is telemetry validated before release?  

The Payoff

By embedding event-driven architecture into CRM platforms, organizations achieve:  

- Faster form loads and smoother subgrid performance.  

- Reduced memory leaks in multisession side panes.  

- A governance model that makes technical compliance procedural, not optional.  

💡 Closing Thought  

Architecture is not just about diagrams—it’s about operationalizing technical patterns so they become invisible guardrails. When event-driven design is baked into CRM delivery, teams stop firefighting performance issues and start scaling with confidence.

Governance & Guardrails in Automotive Digital Platforms

Thought of the Day: Governance & Guardrails in Automotive Digital Platforms  

Working in the automotive industry has taught me that building digital platforms is not unlike building vehicles themselves. The chassis (Platform) must be strong, stable, and standardized, while the body styles (Solutions) bring innovation, differentiation, and customer value.  

But here’s the challenge:  

- Platform teams safeguard stability, uptime, and shared infrastructure.  

- Solution teams drive innovation, features, and customer-facing experiences.  

- Both are essential, yet their priorities often collide.  

Governance and guardrails exist to keep this balance intact. Without them, innovation risks destabilizing the platform. With too much rigidity, governance risks being seen as a blocker.  

Lessons from Automotive Platforms

- A car without a strong chassis is unsafe.  

- A chassis without diverse body styles is uninspiring.  

- The balance lies in guardrails that protect stability while enabling creativity.  

Best Practices for Maintaining the Balance

- Depersonalize governance: Make guardrails procedural, not personal.  

- Embed QA early: Validate platform-impacting changes during development, not after release.  

- Communicate in outcomes: Talk about uptime, safety, and delivery velocity — not authority.  

- Respect autonomy: Solution teams innovate freely, but within guardrails that protect the whole system.  

In automotive digital programs, governance is not about slowing down. It’s about ensuring that every solution team can accelerate safely, knowing the platform will hold steady beneath them.  

Guardrails don’t limit innovation — they enable it.  

#AutomotiveIndustry #DigitalTransformation  

#AutomotiveDigital #Governance  

#PlatformGovernance #DigitalGuardrails #RiskManagement  

#UptimeStability #TechLeadership  

#SolutionTeams #PlatformTeams  

#Collaboration #CRMPlatforms  

#PowerPlatform #Azure  

#DigitalExperience #InnovationWithStability  

#ThoughtLeadership #BestPractices  

#AgileDelivery #InnovationCulture  

#BalanceInLeadership

🚀 Tab-Level Telemetry in Dynamics CRM (Beyond Page Load Times)

Some clients require visibility beyond overall page load times—they want to know how each tab performs individually. Since tab load duration is different from page load metrics in Application Insights, we need a way to capture this detail without compromising UI responsiveness.  

To address this, I’ve implemented a telemetry enhancement that leverages the navigator.sendBeacon() API to asynchronously log tab-level metrics into Application Insights.  

✨ Why this matters:  

Unlike synchronous logging methods, sendBeacon ensures telemetry is dispatched reliably—even during navigation or unload events—without affecting page load performance or user experience.  

📌 Implementation Highlights:  

Trigger: Tab load timer starts on TabStateChange or OnLoad, ends on full render.  

Telemetry Dispatch: Compact payload sent via navigator.sendBeacon().  

Performance Benefit: Non-blocking, thread-safe, ideal for unload scenarios.  

Integration: Custom endpoint feeds into Application Insights for dashboards and anomaly detection.  

🧪 Sample Code Snippet:  

`javascript

function logTabLoad(tabName, durationMs, userId, sessionId) {

  const payload = {

    name: "Microsoft.ApplicationInsights.Event",

    time: new Date().toISOString(),

    iKey: "<YOUR-INSTRUMENTATION-KEY>",

    data: {

      baseType: "EventData",

      baseData: {

        name: "TabLoad",

        properties: {

          tabName: tabName,

          durationMs: durationMs,

          userId: userId,

          sessionId: sessionId

        }

      }

    }

  };

  const endpoint = "https://lnkd.in/gXBcy-Zn";

  navigator.sendBeacon(endpoint, JSON.stringify(payload));

}

// Example usage

logTabLoad("Account Details", 1200, "user123", "session456");

`

This approach aligns with our goal of maintaining UI elegance while deepening visibility into lifecycle performance.  

Curious how do you handle specific indepth telemetry in your Applications. Let's share with each other to improve our knowledge on different concepts. Thanks!

#Dynamics365 #CRMPerformance #ApplicationInsights #SendBeacon #Telemetry #PowerPlatform #Observability #DigitalExperience #TechLeadership

Enhancing Plugin Observability in Dynamics 365 with Application Insights

Over the past few weeks, we evaluated multiple approaches to send richer telemetry to Application Insights from our Dynamics 365 plugins. The goal was simple: improve observability without violating the Dynamics sandbox rules. After validating each approach against Microsoft’s official documentation, here’s what we learned.

Goal

Enable reliable, maintainable telemetry logging from Dynamics 365 plugins to Azure Application Insights.

What We Tried — and What Microsoft Documentation Confirms

Application Insights SDK Integration  

  Dynamics plugins run in a partial trust sandbox, and Microsoft explicitly notes that external assemblies and complex dependencies often fail to load. This matched our experience: the SDK couldn’t run due to sandbox restrictions and dependency conflicts.

DLL Merging (ILMerge / ILRepack)  

  Microsoft does not recommend or support merging large dependency trees for sandboxed plugins. Our attempt confirmed this — too many unresolved assemblies, making the approach impractical.

Lightweight Telemetry via HTTP POST (Final Approach)  

  Microsoft’s guidance allows outbound HTTPS calls from plugins when properly configured.  

  Using HttpClient to send telemetry directly to the Application Insights ingestion endpoint worked flawlessly.  

  We successfully logged custom events enriched with plugin context and validated them using KQL in Azure Logs.

Key Learnings (Fully Aligned with Microsoft Guidance)

- Avoid heavy SDKs inside Dynamics plugins — the sandbox is restrictive by design.  

- Use Secure Configuration for sensitive values like Instrumentation Keys.  

- Lightweight HTTP telemetry is the most reliable, supportable, and future‑proof approach for plugin observability.

Next Steps?

- Standardize this lightweight telemetry pattern across all plugins.  

- Build a reusable Telemetry Helper to simplify adoption.  

- Create Azure dashboards and alerts to monitor plugin health, failures, and performance trends.

Visual Path

If you’re exploring telemetry for Dynamics plugins or want to see the helper pattern we built, feel free to reach out.

#Dynamics365 #PowerPlatform #Azure  

#ApplicationInsights #Telemetry #Observability #PluginDevelopment #D365Developers #MicrosoftDynamics  

#AzureMonitor #KQL #SolutionArchitecture #TechLeadership #Dataverse #powerapps

🧠 Beyond Code: CRM Performance Deep Dive

🧠 Beyond Code: CRM Performance Deep Dive

When plugins are tuned and queries refined, but telemetry still shows high durations… look deeper.

🔍 Diagnostic Layers

- Data Volume: Record count, cascading relationships, index pressure  

- Form Composition: Subgrid load, control rendering, script execution  

- Network Latency: Browser compatibility, user location, client-side delays  

- Usage Patterns: Time-of-day spikes, role-based access, dashboard refreshes  

- Telemetry Gaps: Missing customEvents, lack of correlation, need for custom instrumentation  

🧰 Governance Actions

- Archive old records  

- Use Monitor tool for form breakdown  

- Test latency from key user locations  

- Add targeted telemetry (JavaScript + plugin traces)  

- Correlate performance with roles and time windows