Offboarding a Tableau user without breaking Monday

One person, many owned things

The account is closed in the identity provider. The ticket is marked done. On the Tableau site, six kinds of object still carry that person as owner. Each one behaves differently once the owner stops being licensed.

Workbook

It keeps working. The owner has gone and nobody is accountable for it. Any credentials embedded in it were theirs.

Published data source

The same. Everything downstream of it inherits the problem, and nobody chose that.

Flow

It stops running if it authenticated as the departing user. Downstream outputs quietly hold their last result.

Project

Permissions are inherited from where content sits. A project with no live owner leaves the permission model with no live owner.

Subscription

It either stops arriving or keeps arriving, addressed to somebody who has gone. Both are wrong, and only one gets noticed.

Refresh task

The extract stops updating. The dashboard stays up and goes stale where it stands.

The last one is the expensive one. Nothing about it looks wrong.

The failures that stay quiet

Ranked by how long they usually go unnoticed, longest first.

1. A refresh task with no live owner. The dashboard serves as it always did. The data behind it gets a day older every day.
2. A subscription still sending. Anyone receiving it assumes a report that arrives is a report somebody maintains.
3. Credentials embedded by the person who left. The connection keeps working. It stops when that credential is rotated, or when the account is disabled.
4. A flow that stopped. The data sources it fed still exist and still return rows. The failure sits one hop away from where anybody looks.
5. Content in a personal space. Nobody else can see it, so nobody else can inherit it.

Deciding who inherits what

Reassignment looks technical. It is a business decision. Software can move ownership, and only a person can say where it should go.

• Content with an obvious team: give it to that team’s current lead, not to an administrator.
• Content nobody claims: give it a named holding owner, and put a review date on it. That defers the decision without dropping it.
• Content whose only user was the person leaving: archive it as evidence. Passing it to somebody who will never open it helps nobody.

One pattern is worth resisting: moving everything to whoever is running the offboarding. It is fast, and it feels reversible. A year later it looks the same as having done nothing.

Five risks worth seeing first

The planner finds these five and shows them while the plan is still read only. Nothing has changed yet.

Embedded credentials

The item authenticates as the departing user. Moving ownership does not re-authenticate it. A person has to supply a new credential.

Role mismatch

The proposed new owner has a site role that cannot hold this content. The run stops there, rather than leaving a half-finished state.

A subscription with no live owner

Delivery keeps running under an owner who has gone. Or it stops, and the recipients hear nothing.

A refresh task with no live owner

The schedule survives its owner and the data does not.

A cross-project move

The item would land in a different project, and permissions follow where content sits. The move changes who can see it.

All five appear in the plan phase, which reads and proposes and changes nothing. That is the moment to argue about them.

One ordering rule

One ordering rule carries the whole operation. The user is set to Unlicensed only after every reassignment has succeeded.

The alternative is worth picturing. Release the license first, and let one reassignment fail. Now content sits under an account that can no longer own anything. Getting it back is a support conversation rather than a click.

Sometimes every reassignment succeeds and only the final license change fails. That is the good failure. The content is safe and the license is still held. What remains is one action, taken at your own pace.

The sequence

1. Discover everything the user owns, across all six kinds. A project tree shows only some of it.
2. Read the plan, including the risks, before approving any of it.
3. Choose new owners as people. Defaults are how content ends up nowhere.
4. Approve, and let reassignment run to completion.
5. Only then release the license.
6. Keep the record: what moved, to whom, and who approved it.

Everybody in the room wants the license back. It is still the last thing that should move. Recovering a license takes a click. Recovering a dashboard with no live owner takes an afternoon and a call to somebody on holiday.

The check to run early

Every item above can be found while the person is still there. That is the cheapest moment to fix it. A quarterly ownership review takes about an hour. It removes most of the surprise from every departure after it.

• Content owned by users who are inactive or no longer licensed.
• Content owned by a service account with no named person behind it.
• Subscriptions and refresh tasks whose owner has changed role since they were created.

Migration teams reach the same rule from the other direction. Fix ownership first. Otherwise the problem travels into the new environment intact.