skip to content

In Tableau Cloud, what identity does a scheduled data source refresh use to reach the database?

level: seniorimportance: should knowfreq 45%

answer

  1. nobody is signed in at 03:00
  2. the credential travels with the content
  3. one login serves every viewer
  4. people's passwords expire on a policy
  5. offboarding is a dashboard outage

basics

~20 s

A scheduled refresh runs unattended, so it uses the credentials embedded in the published data source or workbook — one fixed database identity, not the viewer's. If those belong to a person, password rotation or offboarding breaks every dashboard behind them.

solid answer

~50 s

A scheduled refresh runs when nobody is signed in, so it cannot prompt anyone — it authenticates with the credentials **embedded in the published data source or workbook** at publish time. That is one fixed database identity used on every run, and used for every viewer too if the connection is live with embedded credentials. The common failure is embedding a named person's login: when their password rotates, MFA is enforced on their account, or they are offboarded, refreshes for every downstream dashboard start failing — and the failure notice goes to an owner who no longer reads it. The fix is a dedicated read-only service account owned by a team, with its secret in a vault and a rotation runbook that includes re-embedding it in Tableau. On Tableau Cloud, Bridge adds reachability to private-network data and brings its own host identity; it does not replace the embedded database credentials.

code

text · 11 lines
text
Published data source: Sales (Snowflake)

-- option A
connection auth = Embedded credential
  db user = svc_tableau_bi        -> every scheduled refresh runs as this
                                  -> every live-connection viewer reads as this

-- option B
connection auth = Prompt user
  db user = whoever opens the view
                                  -> no unattended refresh possible

go deeper

for a junior

Recall that publishing asks how each data connection authenticates — embed a credential or prompt the viewer — and that a schedule can only run when the credential is embedded, because nobody is there to type one.

for a middle

Explain that the embedded credential is stored with the published content and is a single fixed database identity: it serves every scheduled run and every viewer of a live connection, so its grants define what all of them can reach.

for a senior

Demonstrate the operational judgment: dedicated read-only service accounts, secrets in a vault, a rotation runbook that ends with re-embedding, ownership reassigned before offboarding, refresh-failure alerts routed to a team alias, and awareness of the Bridge host's own identity.

for a principal

Own the estate-wide call: standardize service identities versus per-user SSO to the warehouse, and accept the trade — a shared account collapses warehouse audit trails to one name and pushes accountability and row-level enforcement into the BI layer, which you must then govern and review.

## The question behind the question When you open a Tableau view, two completely different authentications happen. First you prove who you are **to Tableau** (site login, SSO, or a personal access token for API calls). Second, something proves who it is **to the database** behind the data source. Interviewers ask about the second one, because that is the identity that quietly rots and takes a wall of dashboards down with it. ## Where the database credential lives When you publish a workbook or a data source to Tableau Server or Tableau Cloud, you choose, per connection, how it authenticates. The two shapes that matter are: - **Embed the credential** — the username/password, or a saved OAuth credential, is stored with the published content and used automatically. - **Prompt the user** — each viewer supplies their own database credential when they open the view. A scheduled refresh happens at 03:00 with nobody present. There is no one to prompt, so **unattended refresh requires an embedded credential**. A connection set to prompt can be viewed interactively but cannot be put on a refresh schedule in any useful way. That single fact explains most of the behaviour people find surprising: the refresh is not "running as the person who scheduled it" in any database sense, and it is certainly not running as whoever last opened the dashboard. It runs as whatever credential the publisher embedded. The same credential is also what serves viewers of a **live** connection with embedded credentials. So the grants on that one database login define the blast radius: every column and row it can read is reachable by anyone who can build on that published data source, unless you constrain it in Tableau. ## Why a named person's login is the wrong identity An analyst publishes with their own warehouse account because it is what is in front of them and it works immediately. Then, predictably: - Their password rotates on the corporate 90-day policy and the embedded copy is now stale. - Their account gets interactive MFA or a conditional-access policy, which a headless refresh cannot satisfy. - They change teams and lose the schema grant, so the refresh authenticates but returns a permissions error. - They leave, their account is deprovisioned, and every published source they own dies at once. Tableau notifies the **content owner** when a refresh fails, and after repeated consecutive failures it can suspend the task altogether — which means the alert goes to the mailbox of the person who just left, and nobody notices until a stakeholder asks why the numbers stopped moving. Tie this back to ownership: content ownership on the server is an operational assignment, not a credit line. ## What good looks like Use a **dedicated service account per source system** (or per domain), not per analyst: - Read-only, scoped to the schemas BI is allowed to see. - Owned by a team, with the secret in a password vault, and exempt from interactive-MFA policies by design rather than by accident. - A documented rotation runbook whose last step is *re-embed the new secret in every published data source that uses it* — rotating the warehouse password without that step is the single most common self-inflicted outage here. The Tableau REST API can update a connection's stored credentials, which is what lets you script that step instead of clicking through content. - Publish **one certified data source** per subject area rather than embedding credentials in dozens of workbooks; then there is one place to rotate and one place to audit. - Reassign ownership (and verify the embedded credential still works) as part of offboarding, before the account is disabled. The trade-off you must be able to name: a shared service account makes the warehouse's audit log say `tableau` for every query, so per-person accountability moves into the BI layer — Tableau permissions plus user filters using `USERNAME()`/`ISMEMBEROF()` — rather than living in the database. ## Bridge and the on-premises twist Tableau Cloud is outside your network, so it cannot reach a database that only listens inside it. **Tableau Bridge** is a client you install on a machine in your network and link to your Cloud site; it brokers refreshes and, for supported sources, live queries. Two things people get wrong: Bridge does **not** replace the embedded database credential — that still lives with the published data source — and Bridge introduces a *second* identity, the operating-system account the Bridge client runs under on that host, which matters when the connection uses integrated/Windows authentication and which is why a Bridge box that is asleep, patched, or logged out stops refreshes cold. Whether Bridge runs as a service or as an interactive application, and how clients are pooled, has changed across releases — confirm against the version you run. Tableau Server has the analogous knob on the server side: the operating-system account the server processes run under is what integrated authentication presents to the database, distinct from any embedded credential.

  • Why isn't per-user OAuth to the warehouse a clean fix for the shared-service-account problem?
    An OAuth credential in Tableau is saved against an individual user's account, so an unattended refresh still has to embed one person's credential — usually the owner's — and departure or a revoked consent breaks it the same way. Per-user auth also fits live connections better than extracts: an extract is a single materialized snapshot served to everyone, so there is no per-viewer identity for it to honour.
  • What should you do about embedded credentials when you transfer ownership of a published data source?
    Treat it as a re-publish step, not a metadata change. The new owner should verify or re-enter the embedded credential — saved OAuth credentials in particular are bound to the original user's account — then confirm a manual refresh succeeds and that failure notifications now reach the new owner or, better, a team alias rather than an individual mailbox.
  • How does a shared service account interact with row-level security?
    The database sees one login with one set of grants, so it cannot distinguish viewers and database-side row filtering stops helping. Enforcement moves into Tableau: user filters or a data source filter built on USERNAME()/ISMEMBEROF(), applied on a published data source that consumers cannot repoint. Preview as a representative user before publishing, and remember anyone with permission to build new workbooks on that source inherits the account's full reach.
  • Refreshes are green but a stakeholder says a dashboard shows fewer rows than the warehouse. Where does the identity angle fit?
    Check whether the service account's grants shrank. An authenticated connection with narrowed schema or row permissions returns a smaller result set rather than an error, so the refresh succeeds and the numbers are simply short. Compare the row count the service account gets against the same query run as a person, and audit grant changes on that account.

Embedded credentials are the key left under the mat for the cleaner: the work gets done while nobody is home, but the moment the person whose key it is changes their lock, nothing opens — and anyone who knows about the mat has exactly that person's access.

saying these in an interview costs you the question

  • Says the refresh runs as whoever opens the dashboard
  • Thinks a Tableau personal access token authenticates to the database
  • Embeds a named analyst's personal login and calls it done
  • Believes Tableau Bridge removes the need for database credentials
  • Rotates the warehouse password without re-embedding it in Tableau

context

resolving links…