Custom JavaScript visualization for analytics chart not loading after security role update

CRM Microsoft Dynamics 365 Sales
, , , , , , , ,
1

After updating security roles, a custom JavaScript visualization on our analytics dashboard stopped loading for certain users. The chart shows a loading spinner indefinitely and eventually times out.

The visualization uses a custom web resource to render sales performance data in an interactive chart. It worked fine before we restructured our security roles to implement role-based access control for sensitive data. Users with the Sales Manager role can see the chart, but Sales Representatives cannot.

I’ve verified that Sales Representatives have read access to the underlying entities (Opportunity, Account). The web resource is published and the dashboard is shared with all users. No JavaScript errors appear in the console. The issue seems related to web resource security privileges or dashboard script references under the new security model. Has anyone encountered visualization loading issues after modifying role-based access control?

system 2

The problem involves all three focus areas: web resource security privileges, dashboard script references, and role-based access control interaction.

First, web resource security privileges need to be checked at multiple levels. Beyond the Web Resource entity read access, verify that the Sales Representative role has access to any dependent web resources your visualization script references (libraries, CSS files, etc.). Go to Settings > Customizations > Customize the System > Web Resources, find your visualization script, and check Dependencies. Each dependency must be readable by the role.

For dashboard script references, the issue is likely in how the dashboard XML references the web resource. System dashboards in D365 9.1 cache web resource references based on the security context at load time. After role-based access control changes, this cache can become stale. Solution:

  1. Export the dashboard as a solution
  2. Edit the customizations.xml file and increment the web resource version
  3. Reimport and publish

This forces D365 to rebuild the security context for dashboard script references.

The role-based access control aspect is more subtle. Your visualization likely queries data using a specific security context. When you restructured roles, you may have inadvertently removed access to:

  • Saved views that the visualization uses as data sources
  • Custom entities or relationships the script traverses
  • System views that are now restricted by the role hierarchy

To diagnose: Open the browser console while logged in as a Sales Rep, manually execute the data query your visualization uses (via Xrm.WebApi.retrieveMultipleRecords), and check for access denied errors. You’ll likely find a specific entity, view, or field that’s now restricted.

Most common fix: Sales Representatives need Read access to System Views (savedquery entity) if your visualization references system views. Check Security Roles > Core Records > View and enable Read for the Sales Representative role. This is often overlooked when implementing role-based access control.

Finally, verify field-level security profiles. If any fields in your visualization query have field security enabled, Sales Reps must be included in a field security profile that grants Read access to those fields, or the query returns null values that break the chart rendering.

This draft is based on general Microsoft Dynamics 365 Sales knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Web resources have their own security layer separate from entity permissions. Check if the Sales Representative role has read privileges on the web resource entity itself. Go to Security Roles > Core Records tab > Web Resource and ensure Read is enabled. Even if they can access the dashboard, they need explicit web resource read permissions to load custom scripts.

4

Also verify the dashboard ownership. If it’s a user-owned dashboard and you’re sharing it, the web resource references might not resolve correctly for users without ownership. Try converting it to a system dashboard, or ensure the web resource dependencies are properly registered in the dashboard XML. Sometimes role-based access control changes affect how dashboard script references are resolved at runtime.

5

I checked the web resource privileges - Sales Representatives do have Read access on the Web Resource entity. The dashboard is a system dashboard, not user-owned. Still seeing the loading spinner for Sales Reps. Could there be field-level security blocking the data that feeds the visualization?

andr_richardsp 6

Confirmed this resolves the blank chart issue — checking Web Resource Dependencies in the customization editor revealed our D3.js library file lacked read privileges for the Sales Representative role.

7

Field-level security is a good thought. If your JavaScript is trying to retrieve fields that Sales Reps don’t have access to through field security profiles, the query will fail silently and the chart won’t render. Check if any of the fields used in the visualization query have field-level security enabled. You might need to add those fields to the Sales Rep’s field security profile.

8

Don’t forget about the data source itself. If your custom visualization fetches data via Xrm.WebApi or a custom action, the security context matters. Role-based access control changes might have restricted access to the views or queries your script uses. Try running the same data query as a Sales Rep user to see if it returns results. The visualization loads but can’t populate if the underlying data query fails due to permissions.

brandon_verma 9

Sometimes role-based access control changes affect how dashboard script references are resolved at runtime.