How Do You Connect ServiceNow to Power BI?

How Do You Connect ServiceNow to Power BI?

If you opened Power BI Desktop, clicked Get Data, and typed "ServiceNow" into the search box expecting to find a connector, you already know how this story starts. Nothing comes up. The list jumps straight from SAP HANA to SharePoint folder, and the obvious path you were looking for does not exist.

That is not a bug, and it is not something you have missed in a settings panel. Microsoft has never shipped a first-party ServiceNow connector for Power Query, which is the data engine behind Power BI, Excel and Power Query Online alike. You can confirm it yourself in Microsoft's published connector reference: there is no entry under "Service" at all.

So the question is not really where the connector is. It is which of the three real routes into ServiceNow data you should take, and what each one costs you in setup time, maintenance and licensing. This guide walks all three, with the exact API parameters for the one most teams end up using.

What Is the Short Answer?

There is no native ServiceNow connector in Power BI. You get ServiceNow data in by one of three routes:

• The REST Table API through Power BI's Web connector. You build a URL against /api/now/table/{tableName}, authenticate as a ServiceNow user, and Power BI treats the JSON response as a table. No extra licensing, full control, and you write the query yourself.
• An OData feed published by a paid app from the ServiceNow Store. Several vendors sell apps that sit inside your ServiceNow instance, let an admin define a data source in a UI, and expose it as an OData feed. You then use Power BI's OData Feed connector, which is a first-party connector and is listed under "O".
• A generic ODBC or middleware layer. A third-party driver or API gateway presents ServiceNow as a SQL-style source, and you connect with Power BI's ODBC connector.

For most teams building a handful of operational dashboards, the Table API route is the right answer. It is free, it is first-party on the ServiceNow side, and it does not add a vendor to your renewal cycle. The paid-app route earns its cost when non-technical analysts need to define their own extracts without asking a developer for a URL.

Is your reporting stack actually earning its keep? A free SEO and analytics audit from SEO Stuff shows you where your data and your visibility are leaking. Get your free audit.

Why Is There No ServiceNow Connector?

It helps to understand the shape of the problem, because it explains why none of the three routes feels as tidy as clicking a logo in the Get Data dialog.

ServiceNow Is a Platform, Not a Database

Power Query connectors are easiest to build against products with a stable, well-bounded schema. ServiceNow is the opposite. Your instance's tables are substantially your own: custom tables, custom fields on stock tables, extended tables inheriting from task, and a data dictionary that your admins change as processes change.

A connector shipped by Microsoft would have to guess at that. The REST Table API does not have to guess, because you name the table and the fields explicitly in the request.

Reference Fields Make Flat Extracts Awkward

Almost every interesting field in ServiceNow is a reference to another record. An incident's assigned_to is not a name; it is a sys_id pointing at a row in the user table. Its priority is not the word "High"; it is an integer with a label attached in the dictionary.

Any connector has to take a position on whether to hand you the raw value or the human-readable one. The Table API makes that your decision with a parameter, which is more honest and, once you know it exists, more useful.

The Platform Prefers You Use Its Own API

ServiceNow documents the Table API as the supported way to read record data out of an instance, and it is versioned, role-aware and stable across releases. From ServiceNow's point of view, that is the integration surface. The absence of a Microsoft connector is partly just two vendors each expecting the other to build the bridge.

How Do You Connect Power BI to the Table API, Step by Step?

This is the route to learn first. Everything below is built on ServiceNow's own Table API reference.

Step 1: create a dedicated integration user. Do not use your own account, and do not use an admin account. The Table API requires that the calling user have sufficient roles to access the data in the table being requested, so grant read access to exactly the tables you intend to report on and nothing else. When the account later appears in an audit log, you want it obvious what it is for.

Step 2: work out your table name. This is the technical name, not the label you see in the interface. Incidents live in incident, changes in change_request, catalog requests in sc_request. If you are unsure, open the list view in ServiceNow and read the table name out of the URL.

Step 3: build the request URL. The endpoint format is /api/now/table/{tableName}, optionally versioned as /api/now/{api_version}/table/{tableName} with v1 or v2. Against your instance that gives you something of this shape:

https://yourinstance.service-now.com/api/now/table/incident

Step 4: add the query parameters that matter. Hitting that URL bare will work and will also pull far more than you want. The parameters worth knowing:

• sysparm_query takes an encoded query to filter records. It supports =, !=, LIKE, STARTSWITH and ENDSWITH, joins conditions with ^ for AND and ^OR for OR, and sorts with ORDERBY and ORDERBYDESC.
• sysparm_fields takes a comma-separated list of fields to return. Invalid field names are ignored rather than erroring, so check your output. The default is every field, which you almost never want.
• sysparm_limit caps the number of records returned. The default is 10000.
• sysparm_offset sets the starting record index, defaulting to 0. This is how you paginate past the limit.
• sysparm_display_value decides whether you get stored values or display values. It accepts "true", "false" or "all", and defaults to false. Passing all returns both, which is usually what a reporting extract wants.
• sysparm_exclude_reference_link set to true strips the Table API links that reference fields otherwise carry. It defaults to false, and turning it on makes the payload considerably smaller.

A filtered, field-limited request therefore looks closer to this:

https://yourinstance.service-now.com/api/now/table/incident?sysparm_query=active=true^ORDERBYDESCsys_created_on&sysparm_fields=number,short_description,priority,state,sys_created_on&sysparm_display_value=all&sysparm_limit=1000

Note the parameter name-value pair style of filtering, such as appending &active=true directly, is mutually exclusive with sysparm_query. Pick one and stay with it.

Dashboards are only as good as the traffic feeding them. See where your site stands with a free audit from SEO Stuff.

Step 5: connect from Power BI. In Power BI Desktop choose Get Data, then Web, and paste the URL. Authenticate with the integration user's credentials. Power BI will return a single record containing a result list; expand it to a table and then expand the record column into fields.

Step 6: parameterise the instance URL before you publish. Put the instance hostname in a Power Query parameter rather than hard-coding it in every query. The moment you have a development and a production instance, or your company renames its subdomain, you will be glad you did. Our guide to query parameters in Power BI covers the mechanics.

How Do You Handle More Than 10,000 Rows?

This is where most first attempts fall over, and it is worth planning for before you build the report rather than after.

sysparm_limit defaults to 10000, and ServiceNow's documentation is explicit that you use sysparm_offset to page through larger result sets. In practice that means one of three patterns.

Filter it down so the question does not arise. Most operational dashboards do not need every incident ever opened. A rolling window on sys_created_on in your sysparm_query is often the whole fix, and it is the cheapest one.

Build a paging function in Power Query. Write a function that takes an offset, returns one page, and then generate a list of offsets and combine the results. This works and is entirely standard M code, but it is code you now own and maintain.

Pull incrementally instead. For large fact tables, a windowed query combined with Power BI's incremental refresh is the sustainable answer, so each refresh fetches only recent records. That has licensing implications worth reading up on first, and our guide on whether incremental refresh works in Power BI Desktop sets out what you can and cannot do in the desktop application alone.

There is also a pragmatic point here about where the work belongs. Aggregating in ServiceNow, or restricting what you pull, is almost always cheaper than hauling raw records across the wire and summarising them in DAX.

Which Route Should You Use?

The honest answer depends on who is going to maintain this in a year.

Use the Table API when a developer or analyst owns the reporting. It costs nothing, it is fully transparent, and when something breaks you can read the URL and see why. The trade-off is that every new extract is a small piece of engineering, and the knowledge of how it works lives with whoever wrote it.

Use a ServiceNow Store app when the people defining extracts are not technical. These apps are installed into your instance and let an admin configure a data source through a UI, then hand out an OData feed URL that Power BI consumes through its first-party OData Feed connector. You are paying for a self-service layer and for someone else maintaining it against ServiceNow upgrades. Evaluate them on the ServiceNow Store, check what they do about row limits, and run a trial against real data volumes rather than a demo table.

Use ODBC or a middleware gateway when ServiceNow is one of many sources. If you are already standardising a dozen SaaS systems behind one API layer or warehouse, adding ServiceNow to it is more coherent than giving it a bespoke route. If ServiceNow is your only such source, this is a lot of apparatus for one connection.

Consider not connecting Power BI at all. ServiceNow ships its own analytics and reporting capability, and for straightforward operational metrics on ServiceNow data alone, it may genuinely be the shorter path. The case for Power BI is strongest when you need to join ServiceNow data to something that is not in ServiceNow.

What Are the Limitations Worth Knowing?

Authentication is the first thing to settle, not the last. Power BI Desktop's Web connector offers Basic authentication, which the Table API accepts, and that is why most published walkthroughs use it. Treat the integration user's credentials as the secret they are, scope its roles narrowly, and check with whoever owns your ServiceNow instance what your organisation's policy actually permits before you build on it. Instance security policies vary, and this is not a decision to make unilaterally from the BI side.

Reference fields will surprise you once. Pull a dataset with the default sysparm_display_value of false and your assigned_to column is full of 32-character identifiers. Pull it with all and your model doubles in width. Decide deliberately which you need, per query.

Ignored field names fail silently. Because sysparm_fields ignores invalid fields rather than erroring, a typo gives you a dataset that is quietly missing a column. Check the shape of the output the first time, and again after anyone changes the instance's dictionary.

You are querying a production system. A dashboard refreshing an unfiltered query against a large table is a load on the instance that your platform team did not plan for. Filter at the source, schedule refreshes sensibly, and talk to whoever runs the instance before you point a published report at it.

Custom fields are yours to track. Nothing in this pipeline knows that your team added a field last quarter. Reporting on a customised ServiceNow instance is a relationship between the dashboard and the data dictionary, and somebody has to keep it current.

Most teams never check whether their site is working as hard as their dashboards. A free SEO audit takes minutes and tells you where to look.

How Does This Compare to the Alternatives?

It is worth putting this next to the other integrations you may have built, because the pattern repeats across the Power BI ecosystem.

Compared with connecting to a cloud data warehouse, this is more fragile and more manual. A warehouse gives you a stable schema, SQL, and query folding so filters execute at the source. If ServiceNow data is already landing in your warehouse through a pipeline, read it from there and skip all of the above.

Compared with Microsoft's own first-party sources, the contrast is sharp. A Dataverse or SQL Server connection handles authentication through your organisational account with no connection string to construct by hand. The ServiceNow route asks you to assemble the URL yourself. That is the price of there being no connector.

Compared with exporting to a file, the API route is obviously better for anything recurring, but a one-off question genuinely answered by a CSV export does not need a pipeline. Be honest about which one you have.

And compared with other systems that also have no connector, ServiceNow is in reasonable shape. It has a documented, versioned, role-aware REST API with sensible pagination. That is more than many SaaS products offer.

Final Thoughts

The frustrating part of this question is the first five minutes, when you are still looking for a connector that was never there. Once you accept that the Table API is the integration surface, the work is ordinary: name your table, name your fields, filter at the source, paginate deliberately, and keep the instance URL in a parameter.

The broader lesson is one this site keeps running into. The connector you build on is a dependency, and a hand-assembled API URL is a dependency with your own name on it. Document what you built and why, because the person maintaining it in eighteen months may not be you. We made much the same point about a very different integration in our guide to connecting Microsoft Project to Power BI, where the route that every older tutorial recommended stopped existing entirely.

Start with a filtered query against one table, confirm the field names are what you expect, and only then build the model on top of it.

Ready to see what else is leaking? Get a free audit from SEO Stuff and find out where your traffic and visibility stand today.