Problem
A user can access certain tables directly in ServiceNow (e.g., Legal module tables), but when they try to create a new data source in the Power BI Connector for ServiceNow, those tables don't appear in the table selector. Using an existing data source with the same tables works fine — it's only creating a new one that fails. Why?
Solution
This comes down to how table access is validated at different moments, and it's expected ServiceNow behavior.
The connector uses ServiceNow's own out-of-the-box canRead() method to determine table/field visibility, honoring your existing ACLs. When a data source is created by a user, ServiceNow validates that user's access to the selected tables at that exact moment — this is where a restriction can surface if the user's role doesn't grant sufficient visibility (for example, having a base role like legal_user may not be enough; a higher-level role, such as sn_lg_ops.request_admin for the Legal module, may be required depending on how your ACLs are configured for that module).
However, once a data source already exists (created by another user, such as an admin), other users can still view, use, or copy it — even without the same level of permissions — since ServiceNow doesn't re-validate table access the same way for an existing source as it does at creation time.
Practical workaround: if a user's role doesn't meet the ACL requirements to create a new data source with certain tables, have an admin (or a user with sufficient role/ACL access) create the data source instead. Other users can then view, use, or copy that existing data source without hitting the same restriction.
If a specific module continues to restrict access even after confirming roles, you may need to set up cross-scope access and restricted caller access from the Power BI Connector's application scope to that module's scope, per ServiceNow's standard cross-application access model.