Who to hire for Tableau with Salesforce: analyst, consultant or administrator?

A request to "hire a Tableau partner" hides three different jobs. One is building the analysis: choosing the data, shaping it and making a dashboard that answers a question a sales leader or a service manager will actually ask. One is running the platform: deciding who can publish, how content is certified, how extracts refresh and how the environment performs under load. And one is operating a self-hosted Tableau Server, which is infrastructure work. Firms that are good at one of these are not automatically good at the others, and the confusion is why so many Tableau engagements end with a handsome set of dashboards that nobody trusts.

Salesforce acquired Tableau in 2019 and the product kept its name. What has changed since is how it sits beside Salesforce: Tableau Cloud and Tableau Server remain the established products, and a newer Tableau Next platform has been added inside the Salesforce platform. If you are weighing a move between them, should I migrate from Tableau sets out the decision. This page is about the people you hire.

#Three jobs, three credentials

Trailhead lists a separate Salesforce credential for each of the three jobs, and reading the descriptions is the fastest way to decide which person you need.

For analysis, the credential is Salesforce Certified Tableau Data Analyst. Trailhead describes it this way: "Certified Tableau Data Analysts enable stakeholders to make business decisions by understanding the business problem, identifying data to explore for analysis, and delivering actionable insights." The emphasis is on understanding the business problem first. A holder who starts by asking which decision a dashboard supports is behaving as the credential intends.

For design, performance and governance, the credential is Salesforce Certified Tableau Consultant: "Certified Tableau Consultants help customers understand their data and realize business value. They are experts in visual design, performance, scalability, adoption, and governance." This is the person to put in front of your steering group. The list of strengths, which includes performance, scalability, adoption and governance, is the set of things that go wrong after the first release.

For a self-hosted environment, the credential is Salesforce Certified Tableau Server Administrator, and it covers a narrow case: "Certified Tableau Server Administrators have a comprehensive understanding of Tableau Server functionality in a single-machine environment and approximately 6 months of experience." Note the phrase "single-machine environment". Clustered, high-availability or very large deployments go beyond what that credential tests, so ask about that experience separately. If you use Tableau Cloud, much of the infrastructure work disappears and this role matters less.

#The Salesforce-specific skills people overlook

Tableau by itself is a visual analytics tool. Tableau on Salesforce adds three questions that a pure analytics shop may not have faced.

The first is data access. Salesforce enforces record visibility through sharing rules, profiles and permission sets. A Tableau extract of opportunity data that is published to a broad audience may show every user every opportunity, which is not what your Salesforce security model intended. A partner should be able to explain whether they will rely on row-level security in Tableau, filtered extracts, or a different source, and how they will test it with a user who should see little.

The second is the shape of Salesforce data. Objects such as Opportunity, Case and Campaign hold history in separate tables, formula fields that do not extract the way they appear in the UI, and picklists that changed over the years. Dashboards that ignore these produce numbers that disagree with the Salesforce report the same leader looked at an hour earlier. A good partner reconciles first, and shows the reconciliation.

The third is where the dashboard will be seen. Embedding in Lightning pages, publishing to a Tableau site, and delivering by subscription are three different distribution choices, each with a different licence and permission implication. Ask which the partner recommends and why.

Salesforce has also made a statement about packaging. Its analytics pricing page says: "The full power of the Tableau Next platform is now included in Core, Advanced, and Max editions for Sales, Service, and Industry Clouds." That is a reason to check your own contract before you pay for design work on an analytics layer you may already hold. It is not a reason to assume that your Tableau Cloud dashboards need to move. A reputable partner will compare the two on your use cases and say plainly when the answer is to leave things alone.

#Red flags specific to Tableau work

Dashboard volume as a measure of progress. A statement of work that promises thirty dashboards has told you the partner does not know which questions matter. Ask for a small number of workbooks tied to named decisions.

No data model discussion. If the proposal moves from kick-off to visual design without a step to define the data source, joins, grain and refresh, the dashboards will be slow or wrong.

No performance testing. Tableau workbooks degrade in recognisable ways: too many marks, calculations on row-level data that could have been pushed to the source, and live connections hitting a busy system. The built-in performance recording shows where time goes. A partner who has never used it has not tuned many workbooks.

Treating the project as a Tableau Desktop project. Desktop is where a workbook is authored. Governance happens on the site or server: projects, permissions, certified data sources, refresh schedules and who is allowed to publish. A proposal with no governance section is a proposal for a one-off.

Ignoring adoption. The Tableau Consultant credential names adoption as a skill for a reason. Ask how the partner will measure whether people use what is built, and what it will retire.

And a partner who recommends rebuilding everything. Existing workbooks usually contain years of agreed definitions. Some deserve to be rebuilt and many deserve only a tidy.

#A realistic first engagement

The best first piece of work is not a new dashboard. It is an inventory. Ask the partner to produce, from your site's usage data, a list of workbooks by views over the last quarter, by owner and by data source, and to propose a short list to keep, fix and retire. That exercise takes a few days, costs little and shows whether the partner can read your environment.

The second step is one end-to-end workbook on a question your business actually asks, for example pipeline coverage by region against target. The partner should deliver the certified data source, the workbook, a reconciliation against the equivalent Salesforce report, a performance recording before and after tuning, and a one-page governance note covering who may edit it and who must be consulted before a definition changes.

The third step is a handover. Your analysts should be able to change a filter, add a measure and publish a revision without the partner. If they cannot, the partner has built a dependency. Look at integrating Tableau with Salesforce if the data connection itself is the open question.

#Ten questions for a bid or interview

1. Which of your people hold the Tableau Consultant and Tableau Data Analyst credentials, and will they be on our project?
2. How do you decide which dashboards to build, keep or retire in the first month?
3. How will you make sure a user sees only the Salesforce records they are allowed to see?
4. Show us a certified data source you built for another client. How was it tested and who maintained it?
5. How do you reconcile a Tableau number with the Salesforce report it will be compared to?
6. Walk us through a performance recording you used to speed up a workbook. What changed?
7. Do we need an extract or a live connection for this use case, and what does each cost us in refresh and load?
8. Where will the dashboard be consumed, and what does that mean for licences and permissions?
9. How will you measure adoption three months after launch?
10. What will we be able to change ourselves on day one after handover?

Strong answers are specific, and a number of them will start with "it depends on", followed by the factor. Be wary of bidders who answer all ten without asking you a question.

#Checking references and evidence

Ask references what happened after the partner left. Are the dashboards still in use? Did the numbers still agree with Salesforce six months later? Who changed the definition of a closed opportunity, and what happened to the dashboards that depended on it? Ask the reference's analysts as well as the sponsor, because the person who built a Monday morning report will tell you more about a handover than the person who signed the cheque.

Request artefacts you can judge without sector knowledge: a data dictionary, a governance document, a before-and-after performance recording, a usage chart from a site you can be shown. Partners who have run this work well have such things in a drawer. A public Tableau Public profile can show design taste, but it says little about governance, security or support, so treat it as a portfolio and not as evidence of enterprise delivery.

#Commercial models and the statement of work

Fixed price suits the inventory and a defined number of workbooks. Time and materials suits discovery and data clean-up, where the amount of reconciliation is unknown. A monthly allocation suits a business that wants continual analyst capacity, though you should demand regular usage reporting so the allocation does not become habit.

The statement of work should list the workbooks and data sources by name, the question each answers, acceptance tests that include a reconciliation to a Salesforce report and a row-level security test, and the permissions model. It should make you the owner of the workbooks, the data sources and any documentation, held in a project on your site. It should state who maintains refresh schedules, what happens when a source field changes, and the period during which the partner will fix defects at no extra charge. Keep licence quotes on their own paper: Tableau Salesforce implementation cost and the Tableau licence guide cover what you pay Salesforce and what the project involves.

One more point on pricing of the work itself. Dashboard projects overrun mostly because of data preparation, not charting. When two bids differ widely, compare how many days each assumes for cleaning, joining and reconciling Salesforce data, and how many review cycles each allows with your business users. The lower bid usually assumes fewer of both, and the difference comes back as change requests.

#When you do not need a partner

If you have one or two people who already use Tableau well, a handful of dashboards and no governance problem, extend what you have. If your need is a standard pipeline or service report, the reports and dashboards inside Salesforce may be enough, and the first question is whether Tableau is needed at all. And if a single analyst can own a small project end to end, a short paid review of the finished work by a Tableau Consultant is cheaper than a full engagement.

You need a partner when the estate has grown without rules, when numbers disagree across teams, when performance has become a complaint, when a self-hosted server needs upgrading, or when you are about to extend Tableau across the business and want the standards in place before the dashboards multiply.