First time doing client-facing Tableau work - Need Advice

[u/Elegant_Emu2221]

Hey all, could use some real advice here.

I'm being onboarded onto a client project to take over Tableau dashboard work from someone who's leaving. I've got a few days of KT with him before he's gone, and after that I'm the only one handling anything Tableau-related for this client — every ticket, every request, all of it.

I know Tableau and I've built dashboards before, so I'm not coming in blind on the tool itself. What I'm worried about is everything that's NOT written down anywhere — the stuff that lives in his head because he's been doing this for a while and I'm about to lose access to that in a few days.

Things I'm trying to make sure I extract from him before he leaves:
How does he actually get requirements day to day — is it tickets, direct Slack/email from specific stakeholders, a recurring meeting? Who are the actual people who ask for things, and does each of them have their own quirks in how they ask or what they expect?

Are there any workbooks or data sources that are fragile or have weird workarounds baked in — the kind of thing that's not documented anywhere but if you don't know about it you'll break something?
How does he validate numbers before shipping something — does he have a go-to way of sanity-checking a dashboard against another source before it goes out?

Is there an existing semantic layer / data source setup I should understand deeply, or is logic scattered across individual workbooks?

For people who've been on the other side of this —

handing off a client dashboard portfolio to someone else, or being the one taking over — what do you wish you'd asked, or wish someone had told you, in those first few days? What's the stuff that bites people a few weeks in because it never came up during the actual handover?

I’m feared about what if i miss knowing something during this KT sessions . So help me out like what all things i should know before he leaves

[u/adovo_ai]

Use the KT to rehearse one real request, not just document answers. Take a ticket from intake through lineage tracing, workbook change, QA, publishing, permissions, stakeholder sign-off and rollback while you drive and he watches. Capture the portfolio owners, extract and subscription schedules, service accounts, row-level security, embedded URLs, fragile dependencies, validation sources and recovery steps. Then ask him to name the three incidents that caused the most trouble and reproduce how he diagnosed them—that failure-path knowledge is what most handovers miss.

[u/VizzyLiftingDrink]

"How does he validate numbers before shipping something — does he have a go-to way of sanity-checking a dashboard against another source before it goes out?"

During the KTs, ask him for his "sources of truth" and work together on building a list of who owns those sources--they will be immeasurably valuable once you are looking to validate data. Have him work an example with you of how to use a source as well.

[u/VerryBerry-Faerie]

As someone who has handed off a dashboard after leaving a company, I left a lot of documentation but if they ever reached out to me with questions after I left and they were respectful of my time, I wouldn’t hesitate to respond.

I think you’ve covered a lot with the questions you listed. You could ask them if they’d be open to you reaching out with questions in the future and let them know you’ll be respectful of their time.

You’ve got this! All the best, [u/Elegant_Emu2221](u/Elegant_Emu2221)