Decluttering the Dynamics 365 Case Form When Agents Threaten to Go Back to Sticky Notes

Why does a Dynamics 365 case form become slow and cluttered?

Case forms grow by accretion. Every escalation, report request and audit finding adds a field, a subgrid or a script, and nothing is ever taken away, because removing a field feels risky and adding one feels free. The agent pays for all of it on every case they open, dozens of times a day, while typing to a customer who is waiting. When agents say they would be faster on sticky notes, they are usually describing load time and scrolling, not the colour scheme.

The causes below are the ones that actually cost time. Each has a different place where it shows up in measurement, which is why the first job is to measure rather than to redesign the layout.

How do you measure case form load time before changing anything?

Measure per role, on real cases, in the app agents actually use, and separate three kinds of time: network, client script and server. A cluttered layout and a slow plug-in feel the same to an agent and need completely different fixes, so a redesign without this split often moves fields around and leaves the load time where it was.

Write the baseline down in a simple table per role and keep it. It is the evidence for which change mattered, and later it is what you show the agents.

• Monitor: start a Monitor session for the model-driven app from Power Apps and open the cases. It records the form load events with timing detail, the network requests, and form checker entries that show which event handlers and business rules ran and why a control is hidden or shown.
• Browser developer tools: record the network tab while opening a case and export a HAR file so the trace can be compared later or shared. A performance recording shows long script tasks on the main thread, which is where synchronous OnLoad code and heavy controls appear.
• Server time: enable the plug-in trace log for the environment and read the execution time of each step registered on the case table, especially on Retrieve, while you open the same cases.
• Control for the machine: repeat on a second machine and network with a clean browser profile, so a VPN route, an extension or old hardware is not mistaken for a form problem.
• Record per role and per app: a supervisor on a desktop and a first line agent in a multisession workspace can be loading different forms, and the numbers should say which.

What is the ordered declutter pass, from highest payoff to lowest?

Run it in this order. The early steps are configuration that can ship in days and removes most of the visible clutter; the later steps need testing because they touch scripts, server logic and the data model. Each step is measured against the baseline before the next one starts, so you know which change bought the time.

• Step 1. Baseline the load time per role: Open the same small set of real cases as each agent role, in the app they actually use, and record the load time in Monitor and the browser developer tools, separating network, client script and server time. Write the numbers down before anything changes.
• Step 2. Collapse or remove sections on the default tab: Strip the first tab back to what an agent needs in the first minute of a case: customer, product, issue, priority, status and the next action. Sections that are read occasionally move to a later tab; sections nobody reads come off the form.
• Step 3. Move subgrids, quick views and heavy controls off the default tab: Related grids, quick view forms, form components and web resources move to tabs the agent opens when needed, so their queries run when the tab is selected rather than on every case open. Confirm the deferral in Monitor rather than assuming it.
• Step 4. Replace synchronous load-time scripts: Remove synchronous web requests from OnLoad, use Xrm.WebApi promises, enable async OnLoad handlers in the app settings where the load genuinely has to wait, and move logic that only matters later to OnChange, TabStateChange or the server.
• Step 5. Take load-time work off the server path: List synchronous plug-in steps on Retrieve of the case table and calculated columns shown on the form, read their timings in the plug-in trace log, and remove, cache or move to asynchronous processing anything that does not have to run while the form opens.
• Step 6. Defer PCF control initialisation: Where several code components sit on the form, stop them all fetching data in init. Load from the data the platform passes in, fetch the rest when the control is visible or used, and move rarely used controls to a later tab.
• Step 7. Use a quick create form for intake: Give agents logging a new case a quick create form holding only the fields known at the moment of contact, so intake does not open the full case form at all.
• Step 8. Split the main form into role-based forms: Create a main form per role, such as first line, specialist and supervisor, assign each to the security roles that use it, and include only the right forms in each app, so nobody loads the fields and grids another role needs.
• Step 9. Retire fields nobody populated in the last 90 days: For every field on the form, count cases created in the last 90 days where it holds a value, check what depends on it, and remove the unused ones from the form first and from the data model later.
• Step 10. Measure again and show the agents: Repeat the baseline on the same cases and roles, then show the before and after numbers to the agents who complained, alongside the fields and steps that were removed.

How do you decide which case form fields to keep?

By usage, not by opinion. Every field on the form was requested by someone who can explain why it matters, so a workshop about which fields to remove ends with all of them staying. Counting what agents actually filled in ends the argument quickly, and it usually shows a small core of fields doing the work and a long tail that is almost always empty.

• List every field on each case form, including hidden ones and those only shown by business rules.
• For each field, count cases created in the last 90 days where it holds a value, using an aggregate FetchXML query, a view filtered on "contains data", or an export to Power BI. Distinguish fields filled by agents from fields filled by a flow, plug-in or integration.
• Check dependencies before removing anything: the solution dependency view shows forms, views and processes, but not code, reports, Power BI datasets or integrations, so search those separately.
• Remove unused fields from the form first and keep the column. Retire the column from the data model later, once a reporting cycle has passed without anyone asking for it.
• For fields that are needed but not on every case, show them only for the case type or stage where they apply, with a business rule scoped to that form, or move them to a later tab.
• Where required fields are the complaint rather than clutter, move the requirement to the point in the case where the value is known instead of demanding it at creation.

Which is lighter on a case form: a subgrid, a quick view, a form component or the timeline?

Each of these retrieves related data, so each adds work when it renders. The practical rule is to keep only what agents read on nearly every case on the default tab and put everything else where it loads when asked for. The table sets out the trade-offs in general terms; confirm the effect on your own form in Monitor.

How should OnLoad scripts, business rules and plug-ins be changed?

Load-time logic is where a case form loses the most time invisibly, because nothing on the screen shows it. The goal is simple: nothing runs while the form opens unless the agent needs its result before typing. How the code itself should be designed and packaged is covered in our guide to common Dynamics 365 customization mistakes; the points below are specific to form load.

• Synchronous web requests in OnLoad block the browser. Replace them with Xrm.WebApi calls that return promises.
• Where the form genuinely has to wait for a result before it is usable, enable async OnLoad handlers in the model-driven app settings, so the platform waits for the promise within its timeout rather than the script freezing the page.
• Move logic that only matters later out of OnLoad: to OnChange of the field it depends on, to TabStateChange for the tab that uses it, or to the server.
• Remove unsupported code that manipulates the page directly. It is slow, and it breaks on platform updates.
• Review business rules scoped to all forms. Rules that only apply to one role or case type can be scoped to the form that needs them.
• Plug-in steps registered on Retrieve of the case table run on every form open. Read their timings in the plug-in trace log, and remove, cache or move to asynchronous steps anything that does not have to happen while the record is read.
• Calculated columns are computed when the record is retrieved, so a form full of them adds server time. Rollup columns are calculated by a system job rather than on open, so they cost less at load but can be stale, which agents should know.

Why do several PCF controls slow a form down, and what fixes it?

Every code component on a form runs its initialisation as the form loads. One well-built control is rarely the problem. Four or five, each fetching its own data in init, each bundling its own copy of a UI library, and each redrawing when any field changes, is a common reason a form that looks simple loads slowly. Building controls properly, including performance budgets and testing at real data volume, is covered on our PCF controls development page; the load-time fixes are these.

• Use the data the platform already passes to the control rather than querying the Web API again for the same record.
• Defer secondary data until the control is visible or the agent interacts with it, instead of fetching everything in init.
• Keep updateView cheap: compare what changed before redrawing.
• Prefer virtual controls that use the platform React and Fluent libraries over bundling a separate copy in each control, which keeps bundles smaller.
• Page dataset controls and never load every related row on open.
• Move controls agents rarely use to a later tab, the same as a subgrid.

How do role-based forms and quick create forms help case agents?

One case form for everyone means every role loads what every other role needs. Role-based forms fix that at the source. A main form can be assigned to specific security roles, users see the forms their roles allow in the configured form order, and a fallback form covers anyone without an assigned role. The model-driven app, including a Customer Service workspace app, also controls which forms are included at all, so a first line agent app does not need to carry the supervisor form.

Quick create forms solve a different problem: intake. An agent logging a new case from a call or chat needs a handful of fields known at that moment, not the full resolution form. Designing a quick create form for the case table with only those fields keeps intake fast and moves the rest of the detail to the point in the case where it is known.

What if the slow screen is the schedule board or the whole platform?

A case form is one screen; the method above applies to any model-driven form. The Field Service schedule board is different enough to have its own diagnostic, which is set out in our health check section on slow schedule boards and is not repeated here. Where every screen is slow, the flows fail and customizations were made directly in production, the problem is the build rather than one form, and the Dynamics 365 health check is the right starting point.

Sometimes the honest finding is that the platform itself is the wrong fit for the service operation, not just the form. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. For organizations that need a service desk without per-user Microsoft licensing, custom CRM development on React, Node.js, PostgreSQL or .NET is the alternative.

How do you show agents the change, and what does Solzet deliver?

Show the numbers. Put the baseline and the new load time per role side by side, list the fields and steps that were removed, and name the agents whose complaints led to each change. That is what turns a team threatening to go back to sticky notes into one willing to try again, and it is the natural starting point for the role-based work described on our adoption and training page.

Solzet runs this as a fixed-scope piece of work on Dynamics 365 Customer Service and other model-driven apps: the measurement, the declutter pass, script, plug-in and PCF fixes, role-based and quick create forms, and the before and after evidence. Senior consultants and full-stack developers with 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery do the work remotely from Yerevan, Armenia, in your tenant through accounts you create and can revoke, with changes shipped through solutions rather than made in production. The wider scope of a service implementation is on our Dynamics 365 Customer Service page.