Living with personal access tokens: ownership, expiry and rotation

Every token belongs to a person

A personal access token is issued to a named person, in their name, and it carries exactly the Tableau permissions that person already has. That is what makes it worth building a governance boundary on: anything done with it is something the owner could have done anyway, and every audit line downstream carries their name honestly.

It also makes the token an administrative object, not a technical one. It has an owner, the owner has a team, and the team has a rota. Almost every awkward thing on this page follows from that one fact.

The first artefact worth having is a register: one row per token, naming the job it drives, the person accountable for it, where it is stored, and the date it expires. Four rows take ten minutes to write and answer the question that otherwise takes a morning, which is this: if I revoke this, what stops.

One live session per token, and how to plan around it

Tableau Cloud allows one live session per token. Each new sign-in using that token ends the session before it, which is comfortable while one person is using it and awkward the moment two things are.

The suite is built around that behaviour rather than against it. The gateway signs in once, mints a single Tableau session, and hands that one session to each tool. The tools share it instead of each signing in again with the same token and invalidating the sign-in before them.

The same rule shapes how a long job behaves. Before a migration run against a Cloud source is approved, the pre-flight preview says it in as many words: use a token dedicated to this run, under a name nothing else uses, and make sure no schedule, browser tab or second device shares it. The run retries authentication failures in spaced rounds: one collision is survivable, but a client that keeps signing back in with the same token will still starve it. A Server source tolerates concurrent sessions on one token, which is why a habit that was harmless for years can surprise a team on their first Cloud run.

A scheduled job and a person appearing to interfere with each other is usually this, and it presents as intermittent product flakiness, and seldom looks like the credential problem it is. Check which token each side is holding before investigating anything else.

What expiry does to an automation

A token has an expiry, and an automation built on it inherits that date without ever mentioning it again. The failure then arrives at the next scheduled run rather than at the moment of expiry. The gap between the token dying and anybody hearing about it is one full cadence. On a monthly job, that is a month.

Two settings are worth reading on your own site, not assumed: the expiry an administrator set when the token was issued, and whatever your site does with a token that has sat unused. A token driving a quarterly job spends most of its life idle, which is the combination that catches teams out.

Where a scheduled run can fall back from the personal token to a service credential, the design response is small but decisive: which credential actually authenticated is recorded on the run and shown on the row. Without that record, a silent fallback stays unrepaired, and the problem surfaces only when the fallback itself fails.

A failed run still arms its next fire: a schedule that stops advancing stays permanently due, and the runner keeps reaching for it.

When the owner of a token leaves

The account goes and the token goes with it. That is correct behaviour, and it is also the moment several unattended jobs stop at once without any of them appearing in the leaver checklist.

A person on a Tableau site can own six kinds of thing: workbooks, published data sources, flows, projects, subscriptions and refresh tasks. Their tokens are a seventh, and unlike the other six a token shows up in no project tree at all. Deal with it in the same hour you deal with the content they own, or a schedule will find it for you.

• Reassignment needs a target who can own the content: a Creator-tier role, an Explorer permitted to publish, or an administrator role. A target outside that set is a role mismatch, and it is worth catching in the plan, before the run is halfway through.
• Every item gets a named new owner. A reassignment target is always required: content is moved, never removed on the way through.
• Content carrying embedded credentials is flagged separately, because handing a data source to a new owner does not re-authenticate its connection.
• The license is worth recording as it is released. The site role maps to a tier, and the run records what was reclaimed, the figure a finance conversation asks for three months later.

Offboarding and token hygiene are the same discipline seen from two ends. A register that names the person accountable for each token turns the leaver conversation into a lookup instead of an investigation.

Rotating a token while the work keeps running

Rotation goes wrong when it is performed as a swap. Performed as an overlap it is uneventful.

1. Issue the new token first, named for the job it will drive, with a fresh expiry you write down the same minute.
2. Install it wherever the old one lives. Installing replaces the previous credential rather than joining it.
3. Run the job once by hand, then read the row. It has to say the personal token authenticated, not the service credential.
4. Revoke the old token only once that row is green.
5. Put the new expiry in a shared calendar a fortnight early, and treat the entry as the work itself, not a reminder.

The install step is safe to perform while work is in flight. A locked credential is written to a temporary file and then moved into place, so a run starting mid-rotation reads either the old credential or the new one and never half of a file.

Step three is the one people skip, and it is the only step that proves anything. If the run succeeds on the service credential, the personal token is already broken, the rotation has tested nothing, and you have just revoked your evidence.

Where a token is locked in by an administrator for a hosted deployment, the sign-out control is deliberately hidden, because the next page load would reconnect it anyway. That credential is changed in the admin console instead, which is where anybody looking for it will think to look.

Where the credential lives when nobody is signed in

Secrets in this suite are session-only, which holds cleanly until a job has to run at half past two with nobody there. The exception is explicit, narrow, and worth understanding before you rely on it.

• The scheduler holds the schedule, the cadence and the retention. It deliberately holds no credential of its own.
• The secret is resolved server-side and handed to a short-lived endpoint that signs in, captures what it came for, and signs out again.
• A locked token is encrypted at rest, never logged, and never echoed back to a browser: the status call returns the token name only. One click removes it.
• Under a machine key, each user scope seals its credential with its own derived key. One person’s token cannot be read using another person’s.

One line in that list does more work than it looks. The site a schedule points at is stamped server-side from the live session, never read from the request, because a caller able to set it could aim a scheduled run at a different site while holding somebody else’s credential.

A routine that survives a busy quarter

1. Review the register when somebody joins or leaves, not on a quarterly cycle nobody honours.
2. Give every unattended job its own token. Sharing one with a person is what produces the sign-out nobody can explain.
3. Read the recorded credential on scheduled runs once a month. Two minutes, and it is the only place a silent fallback surfaces.
4. Rotate by overlap: issue, install, prove one run, then revoke.
5. Keep the row of a revoked token and note the date beside it. The history is what makes the next investigation short.

All of it is ordinary. It is the one part of credential management no interface ever prompts anyone to do. Write it down once and keep it.