Tags: Relational databasesReportingDesktopCommand line
A workbook that has run every Monday for three years opens with an error, or the SharePoint Lists entry an analyst always used is missing from the Connect pane. Searching for it brings up a Tableau help page headed “SharePoint Lists (retired)”, a link to a Tableau Exchange download, and forum threads where people ask whether MFA works now and get answers that disagree.
This post covers what Tableau changed and when, what the replacement connector needs, why its refreshes take longer as a list grows, and a route that puts the list in a database Tableau already knows how to read. The Tableau facts come from Tableau’s own help, read on 23 October 2026; those pages are named here and not linked.
Is the Tableau SharePoint list connector deprecated?
Yes, and by now it is retired. Tableau’s help page “SharePoint Lists” carried a warning from 2023 into 2025 that the connector “is deprecated as of the 2023.1 release”, and that a deprecated connector is typically retired 1 to 2 releases later. Once retired, the page said, the connector disappears from the Tableau interface and data sources built on it “will no longer work as expected”.
The same page today is titled “SharePoint Lists (retired)”. Its warning reads: “The SharePoint Lists connector has been retired. The SharePoint Lists connector was replaced by the SharePoint Lists JDBC connector on the Tableau Exchange.” It applies to Tableau Desktop, Tableau Server, Tableau Cloud and Tableau Prep.
So a workbook built on the old bundled connector has two ways forward: rebuild its data source on the JDBC connector, or point it at a copy of the list somewhere else. Both need the data source to be rebuilt, so it is worth deciding which before anyone starts.
Tableau’s SharePoint Lists (JDBC) connector, step by step
The replacement is a connector and a driver, installed separately. Tableau’s help page “SharePoint Lists (JDBC)” says it “requires Tableau 2022.3 or later and the SharePoint Lists JDBC driver”. To set it up on Tableau Desktop:
- Download the connector file from the “Sharepoint Lists (JDBC)” listing on Tableau
Exchange. It is a
.tacofile, and it goes in the Connectors folder of your My Tableau Repository. - Download the JDBC driver from Tableau’s driver download page and put the
.jarfile in Tableau’s Drivers folder. - Start Tableau, open Connect, and under To a Server choose SharePoint Lists (JDBC).
- Enter the site URL, choose SharePoint Online or On Premise as the edition, pick an authentication method, and sign in.
On Tableau Server, the help page says both the connector and the driver “must first be installed on each server node”, followed by a restart, and OAuth needs extra server configuration on top. Every upgrade and every new node repeats that.
The page also lists the API permissions to grant Tableau in SharePoint: profile,
openid, email, AllSites.Manage, offline_access and User.Read. A manage-level
scope across all sites is the kind of request a security team stops to read, so raise it
with them before the morning a dashboard is due.
One cost note from the Exchange listing: the driver carries no licence fee when you use it through this connector, and licence fees apply if you use the same driver through Tableau’s generic Other Databases (ODBC) connector or outside Tableau.
Does the Tableau SharePoint list JDBC driver support MFA?
The answer depends on which connector you are asking about. The retired connector’s help page carried a plain note: “Multi-factor authentication (MFA) isn’t supported by the drivers currently available for Sharepoint Lists.” Its sign-in choices were username and password, third-party SSO and integrated authentication. In a tenant that enforces MFA, that connector was a dead end.
The JDBC connector’s page has no MFA note. It lists Azure AD alongside Username and Password, NTLM, ADFS and Basic, and for Azure AD you select Sign In. We read that as signing in through Microsoft’s own sign-in page, the same route other OAuth apps use in an MFA tenant, though Tableau’s page does not mention MFA either way. Tableau recommends registering your own custom OAuth client in Entra ID for it, so your IT policies control the app and you are not tied to Tableau’s client rotation.
If a sign-in still fails, start with the method: it should be Azure AD, since a username and password typed into Tableau has no step where an MFA prompt can appear. Then check that the custom OAuth client has the permissions above consented. On Tableau Server, also work through Tableau’s “Configure Azure AD for OAuth and Modern Authentication” page.
Why SharePoint list extracts get slower to refresh in Tableau
Every refresh reads the whole list. The JDBC page is explicit: “Tableau supports only extract connections for SharePoint lists, not live connections. You can update the data by refreshing the extract; incremental refreshes are not supported.”
On a list of a few hundred items that is fine. On a list of tens of thousands, every scheduled refresh pages through every item over the network, including the items nobody has touched since last year. Each of those reads counts against SharePoint Online’s throttling limits, which the tenant shares with every flow, app and sync job reading SharePoint at the same hour. Refresh more often to keep a dashboard current, and you read the whole list more often.
There is no live option to fall back on, so a dashboard is always as old as its last successful extract. A refresh that fails overnight leaves Monday’s numbers on screen with nothing on the dashboard to say so unless someone set up a failure alert.
The workarounds people reach for are a Power Automate flow that writes the list to a CSV or an Excel file on a schedule, or a PowerShell script that does the same into a staging table. Both move the same full read somewhere else, and both break when someone renames a column.
What a database copy changes for Tableau
Tableau’s database connectors do not have either restriction. Its “Microsoft SQL Server” and “PostgreSQL” help pages describe the usual connection: a server, a database, a sign-in and optionally SSL, then tables or custom SQL. Both apply to Tableau Desktop, Server, Cloud and Prep. A table in either database can be used live or as an extract, and an extract on one can be refreshed incrementally.
SPSync replicates SharePoint lists into those databases. The first run copies each list into its own table, and later runs use Microsoft Graph delta reads to fetch only the items that changed, on a schedule as short as a few minutes. A reconcile, weekly by default, checks the copy against the list. Tableau then reads the table, and SharePoint is no longer part of the refresh at all.
The copy is shaped for joins. A lookup column becomes {col}_id with the target item’s id
and {col}_value with its display text. A person column becomes {col}_user_id, pointing
at one shared sp_users table, and every row carries sp_modified, sp_author_id and
sp_editor_id. Multi-value columns get a child table each. A deleted item keeps its row
with sp_deleted_at set, so filter on sp_deleted_at IS NULL for current items. The
column type map lists every mapping and which
ones are still being verified on a live tenant.
The copy is one way. People keep editing the list in SharePoint, and the database follows. SPSync does not carry SharePoint item permissions into the database, so grant Tableau’s database account access with the same care you give the list.
How do you connect Tableau to a SharePoint list through SQL Server or PostgreSQL?
Once the list is replicated, it is a normal Tableau database connection:
- In Tableau, open Connect and under To a Server choose Microsoft SQL Server or PostgreSQL. Both use drivers from Tableau’s driver download page.
- Enter the server name, and for PostgreSQL the database name. Choose Windows Authentication or a username and password for SQL Server, or integrated authentication or a username and password for PostgreSQL, and tick Require SSL if the server needs it.
- On the data source page, drag the list’s table onto the canvas, and its lookup tables
alongside it, joined on
sp_item_id = {col}_id. - Add a data source filter on
sp_deleted_atbeing null, so deleted items stay out of the counts. - Choose Live or Extract, then publish.
A join that the old connector could only do in Tableau after loading both lists is now a join in the database. If you turn on reporting views, SPSync generates one per list that already resolves person names and leaves out deleted rows, so the data source can be a single view.
The PostgreSQL page adds one caution worth reading before you connect through a pooler:
Tableau does not recommend pgBouncer, “since Tableau relies on stateful connections”, and
says that if you must use it, keep server_reset_query=DISCARD ALL.
Live connection or extract on the replica
Use a live connection when the dashboard should show what the list says now, give or take the sync interval. Tableau sends its queries to SQL Server or Postgres, which answer them from an indexed table, so a list of tens of thousands of rows is no burden.
Use an extract when the database is far from Tableau, or when many people open the same dashboard and you would rather Tableau’s own engine served them. A full extract refresh against the replica reads from the database, so SharePoint throttling no longer applies to it.
Be careful with incremental extract refresh. Tableau’s “Refresh Extracts” page says an
incremental refresh adds “only the rows that are new since the previous time you extracted
the data”, based on a date column or an id that increases. A SharePoint list is edited in
place, and deleted items are soft deleted with sp_deleted_at, so an incremental refresh
on sp_modified would add an edited item a second time and never see a deletion. Keep
incremental refresh for lists people only add to, and use live or a full extract for the
rest.
For Tableau Cloud, where the database lives decides the route. Tableau’s help on keeping data fresh says that data hosted on a cloud platform and reachable from the internet is queried from Tableau Cloud directly, after you add Tableau Cloud’s IP ranges to the database’s allowlist. A database on your own network goes through Tableau Bridge, which supports live connections and scheduled extract refreshes from inside your network.
Setting it up
- In the SPSync desktop app, connect the site, tick the lists the workbook uses and every
list their lookups point at, and choose SQL Server or Postgres as the destination.
From the command line,
spsync export-configwrites the same replication with--lists-by-name, so it can live in the repository next to the workbook. - Turn on reporting views if the workbook should get person names without writing the joins.
- Run the first sync. Later runs read only what changed.
- In Tableau, rebuild the data source on the Microsoft SQL Server or PostgreSQL connector as above, swap it into the workbook, and check the field names against the old ones.
- Choose live or a full extract, publish, and retire the CSV export or the JDBC data source.
The Tableau, Looker, Metabase and Grafana page covers the same route for the other BI tools, and the SQL Server and PostgreSQL pages cover each destination. If Power BI reads the same lists, the refresh problems it meets are in why Power BI refreshes on SharePoint lists slow down.