Power BI Connector for ServiceNow
Power BI Connector for ServiceNow
Breadcrumbs

ServiceNow Permissions & Power BI Connector

Introduction

ServiceNow Access Control Lists (ACLs) are security rules that control access to data. They define who can read, create, update, or delete records (CRUD) at the table or field level.

ACLs help protect data by requiring users to meet specific criteria - such as roles, conditions, or scripts - before they can interact with records. You need security admin privileges to create or modify ACLs.

Key Components of ServiceNow ACLs

  • Types:

    • Table-level: Secures rows (for example, incident.none).

    • Field-level: Secures columns (for example, incident.short_description).

  • Operations: CRUD (Create, Read, Update, Delete).

  • Evaluation criteria:

    • Roles: Users must have the required role (fastest evaluation).

    • Conditions: The record must meet defined conditions (for example, Active is true).

    • Scripting: JavaScript returns true or false for complex logic.

    • Security model: "Deny by default." If no rule passes, access is denied.

ACL Evaluation Order & Performance

  1. Roles: Checked first as they are cached.

  2. Conditions: Evaluated next.

  3. Scripts: Evaluated last, as they can slow performance.

Important Tips

  • Security admin role: You must elevate privileges to edit ACLs.

  • Table.none vs Table.*:

    • Table.none restricts access to rows, while Table.* applies to all fields in a table.

  • Testing: Always test ACLs using the Impersonate User feature.

  • Best practice: Use roles instead of scripts when possible to improve performance.

ACL Validation Model in Power BI Connector

The Power BI Connector app relies entirely on ServiceNow out-of-the-box (OOTB) ACL validation mechanisms for access control. It doesn’t implement custom security logic or override ServiceNow’s native ACL evaluation.

The app uses standard ServiceNow GlideRecord access validation methods, including:

  • canRead()

  • canWrite()

  • canCreate()

  • canDelete()

These methods evaluate all applicable ACLs, including:

  • Table-level ACLs

  • Field-level ACLs

  • Role-based ACLs

  • Condition-based ACLs

  • Script-based ACLs

Why Behavior May Differ From Backoffice

In some scenarios, users might notice that access works in the Backoffice UI, but the Power BI Connector returns false during validation.

This behavior can occur because ServiceNow ACL evaluation is complex and context-dependent.
For example:

  • Multiple ACLs can apply to the same table or field.

  • A single ACL that returns false can override others.

  • Field-level ACLs can restrict access even if table-level access is allowed.

  • Scripted ACLs can behave differently depending on the execution context.

  • Cross-scope access restrictions can apply.

  • UI rendering might not fully reflect underlying ACL validation logic.

Because the Power BI Connector relies strictly on ServiceNow’s native canRead() and canWrite() methods, it reflects the actual ACL evaluation result - even if the Backoffice UI appears to allow access.

Important Clarification

The Power BI Connector:

  • Doesn’t modify ACL logic.

  • Doesn’t bypass security.

  • Doesn’t implement custom permission handling.

Instead, it strictly follows ServiceNow’s built-in security model.

If access validation returns false, the root cause is typically:

  • An ACL configuration issue

  • Field-level restrictions

  • Scripted ACL logic

  • Cross-scope restrictions

  • Role inheritance differences

Recommendation

If access discrepancies occur:

  • Enable ACL Debug.

  • Impersonate the affected user.

  • Review all applicable ACLs.

This helps identify which ACL returns false and causes access to be denied.

This behavior is expected and aligns with ServiceNow’s standard security model.

Use Case

Problem

When using the Power BI Connector for ServiceNow to retrieve data from the alm_hardware table, the Serial number field doesn’t appear in the selection list. While ServiceNow administrators can see this field in the UI, it isn’t available in the connector.

Solution

This issue occurs because the Serial number field is restricted by an Access Control List (ACL). The field is governed by the following ACL:

  • ACL sys_id: 0dbc2aac1b1020002502fbcd2c071347

The Power BI Connector retrieves data at the field level rather than the record level, which can conflict with ServiceNow’s default security behavior:

  • The app uses the standard record.canRead() method. If ServiceNow can’t validate a specific ACL condition (for example, quantity = 1) for a field-level request, it returns false and blocks access.

  • In the ServiceNow UI, a failed ACL may hide only the field while still displaying the rest of the record. However, the app requires successful validation to export the field; otherwise, the field is excluded.

To make the field visible in the app, adjust the ACL settings:

  1. For administrators: Enable the Admin overrides option on the ACL to allow administrators to access the field in the Power BI Connector.

  2. For non-administrators: Modify or deactivate the ACL (sys_id: 0dbc2aac1b1020002502fbcd2c071347) to remove record-level conditions that the connector can’t validate.

  3. Workaround: https://help.tempo.io/kb/latest/how-to-fetch-the-serial-number-and-asset-tag-fields-from-the-alm_hardware-alm_asset-tables