External Access to Experience Pages with PAR Dashboards

[Luis Estéfano]

External Access to Experience Pages with PAR Dashboards

🟢 What’s the Scenario?

In some projects, especially in industries like telco, there’s a need to expose dashboard-style visualizations to external users (e.g., users with the snc_external role). These dashboards are often built in UI Builder using Performance Analytics Reporting (PAR) components.

However, the new OOTB PAR tables and structures are not designed for external access, making this setup complex and time-consuming when trying to share via portals or Experience pages.

---

⚠️ The Challenge

Out-of-the-box tables and access models used by PAR dashboards:

• Are locked down for internal use.

• Require extensive ACL and UX configuration to be externally available.

• Do not include simplified sharing tools for customer-facing portal views.
  
  

---

✅ The Expectation

Teams expect a simplified and secure way to allow external users to:

• View Experience Pages with dashboards and analytics.

• Access their own CI-related data via a self-service portal.

• Avoid deep customization and rule overrides.

---

 

🛠️ Solution Overview

Depending on your ServiceNow release, instance configuration, and the specific PAR components included in your UI Builder page, you may need to apply additional security settings. Below is a baseline step-by-step guide to help you configure secure external access to PAR components within Experience pages.

---

🔐 Step-by-Step Configuration

1. Grant Access to the Experience Page

a. Add Role in Experience Settings:

• Navigate to the Experience settings in the UI Builder.

• Add the snc_external role under Roles section by using "Open access controls" link.

b. Define Public Audience:

• Create a User Criteria for the "public" audience (mapped to publice user role).

• On the target Experience Page, add the newly created Audience to allow public access.

c. Create ACLs for Experience Page route:

• You must create two ACLs:
  

ACL Type	Name	Operation	Notes
ux_page	Replace slashes in the workspace URL with dots (e.g., now.experience-my-page)	read	Controls page-level access
ux_route	Same as above, but with .* at the end (e.g., now.experience-my-page.*)	read	Controls route-level access

• Include roles such as snc_external or your custom external role.

---

 

2. Enable Access to Visualization Data

Create ACLs on the relevant data tables used by visualizations (e.g., incident, cmdb_ci, ...)

ACL Type	Table / Field	Operation	Notes
record	e.g., incident	report_view	For record level access
record	e.g., incident.*	report_view	For field level access

• Assign roles like snc_external or your custom external one.

• Note: You can now restrict data visualizations to specific roles or conditions. This means that even if the Experience Page is publicly accessible, the data displayed through PAR components—sourced from various tables—will only be visible to the intended audience, ensuring secure and role-based access control.

---

 

3. Optional: Adjust System Properties

These system properties may impact behavior:

Property	Description
glide.ux.user_criteria_enabled	Enable User Criteria over role fields for UX variants.
glide.rest.global.honor_snc_internal_flag	Set to false to relax snc_internal restriction for REST APIs when using explicit roles.

---

 

4. Additional ACLs (Depending on Setup)

Depending on the instance release and the different PAR components you need to use on your page, you may also need to adjust the following ACLs:

ACL Type	Table / Field	Operation
REST_endpoint	/api/now/par/dashboards/analytics/components	execute
record	sys_ux_app_config	read
record	sys_viz_data_source	read
ux_route	now.platform-analytics-workspace.*	read
record	Aditional ACLs on PAR Configuration tables, the tables with "par_" prefix	read
xxxxx	Aditional ACLs to be adjusted depending on instance configuration and Page components used.	read

---

🧠 Best Practices

• Always test access using a real external test user.

• Monitor browser/network logs for 403 errors—these often indicate missing ACLs.

• Document any custom roles and ACLs for future maintainability.

---

📌 Summary

Enabling external users to view Experience Pages with PAR components requires:

• Proper role/audience configuration in UX.

• Explicit ACL creation at UX and data levels.

• Review of system properties and REST access rules.

• Note: Tested on Xanadu release

Though not yet fully OOTB-ready for external use, with the right setup, you can still deliver powerful, secure dashboards to external users.

---

If you run into any issues or need further clarification, please don’t hesitate to reach out.

I hope this helps! 😊👍

Kind regards

Luis Estéfano

Principal Solution Architect, Workflow
Customer Outcomes ITSM

[KentT]

I was able to share the dashboard with the external user by implementing your method. However, one of the filters(source:account) is not functioning properly—it gets stuck in the loading state and doesn't populate the data. Could you advise me on where to make adjustments so that it populates the data correctly?

[Luis Estéfano]

As described on Step 4, you could need aditional ACLs depending on the instance configuration. Check what is the resource you cannot acccess, and open via ACL, by selecting the correct ACL for each type of  resource.

[dss]

Hi Community,

I have 1 query on above topic. Can we pull external tool data like MSDynamics 365, PowerBI application and configure performance analytics in ServiceNow using external tool's API (without storing data in ServiceNow table or custom table)?

Helpful if you can answer.

Thanks in advance.

[IvanoG]

Does this applies also to Zurich?

[kamilpodkow]

I followed the steps described in this article to grant external users access to PAR dashboards on an Experience page (custom workspace dashboard).

My external users have the roles snc_external + pa_viewer, and the dashboards and all their components are visible on the page.

However, when the page loads, all dashboard widgets show "Loading visualization data".

Only after clicking the Refresh button manually do the widgets actually load the data.

Users have read access to pa_dashboards, pa_scores, sys_viz_data_source .

The dashboards’ View roles include pa_viewer

Has anyone encountered the same issue?

Is there a recommended way to ensure the dashboards load data automatically for external users without requiring a manual refresh?

[Maryna K]

Hi kamilpodkow,

I have the same problem and it seems to me I've already checked everything. Did you find a solution?

Best regards,

Maryna

[Luis Estéfano]

Hi @kamilpodkow  and @Maryna K,

Thanks for the detailed description, this is a known pattern I've seen in similar configurations.

The "Loading visualization data" behavior that resolves after a manual refresh usually points to a timing/sequencing issue where the PAR components attempt to fetch data before the external user's session has fully resolved all ACL evaluations. A few things to check:

1. REST endpoint ACL
   Make sure you have an explicit ACL on the `/api/now/par/dashboards/analytics/components` REST endpoint (as noted in Step 4 of the article) with execute access for your external role. A missing or partially configured REST ACL can cause the initial load to fail silently, while the refresh triggers a second request that succeeds once the session is fully established.
   
   
2. Additional PAR table ACLs
   Beyond `pa_dashboards`, `pa_scores`, and `sys_viz_data_source`, check whether your widgets rely on other `par_*` prefixed tables (e.g., `par_dashboard`, `par_component`, `par_filter`). Missing read ACLs on any of these can cause the initial render to stall.
   
   
3. Browser network tab
   Open the browser dev tools as the external user and watch the network calls on first load. Look for any 403 or 401 responses — these will tell you exactly which resource is being blocked. After clicking refresh, compare which calls succeed.
   
   
4. System property `glide.rest.global.honor_snc_internal_flag`
   Confirm this is set to `false`. If it's still `true`, the initial REST calls may be rejected for external users until the page retries.
   
   
5. Caching behavior
   In some cases, adding the external role to the `sys_ux_app_config` read ACL resolves the timing issue, because it allows the UX framework to fully resolve the page configuration before the PAR components start requesting data.
   
   

I'd start with the network tab analysis, that usually reveals the root cause quickly.

Hope this helps!

Kind regards,
Luis Estéfano