Who to hire for Waii on Salesforce

Most people picture Waii as a chat box that writes SQL. The announcement describes something more demanding underneath it. Waii built "a dynamic metadata knowledge graph", one that represents "not just database schemas, but the intricate relationships between tables, columns, business metrics, and governance rules." The SQL generation is the visible part. The valuable and hard part is the graph: what a column means, which join is the sanctioned one, and which rules decide who may see a number. That is why the people to hire are data modellers and governance specialists first, and Agentforce builders second.

The timeline is short and worth stating accurately. Salesforce announced the agreement on 7 August 2025, and Salesforce completed its acquisition of Waii on August 15, 2025. The announcement said Salesforce plans to integrate Waii into Data Cloud, where it would power agentic workflows "across the Salesforce platform, including Agentforce and Tableau Next", and form the foundation of Tableau's next-generation semantic engine. Then the product renamed. As of October 14, 2025, Data Cloud has been rebranded to Data 360. we could not verify a generally available, separately licensed Waii product inside Data 360 as at 13 October 2026, so scope the work against what Salesforce documents today and ask the partner to show you current screens, not the announcement.

#Why this is not a chatbot project

A chatbot project is judged on conversation. A language-to-SQL project is judged on whether the number is right. Take a plain question such as "what was revenue last quarter". Somewhere in your warehouse there may be a gross figure, a net figure, a booked figure and a recognised figure, each in a different table, each correct for a different audience. A system that picks one silently has produced a confident wrong answer. The Waii announcement itself concedes that the problem "demands more than simple text-to-SQL translation", citing accuracy, security and context.

So the partner's first job is to run a definition workshop, and the output is a short, owned list of metrics and joins. Only then does anything get connected. If a proposal begins with a demo against a sample dataset and ends with go-live, it has skipped the part that decides whether anyone trusts the answers.

#The people and skills to look for

The most relevant credential is Salesforce Certified Data 360 Consultant. Trailhead's page says: "Preparing to take the Data 360 Consultant exam? Check out this trail." The official exam guide lists six sections: Solution Positioning; Data 360 Setup and Administration; Data Source Connection and Ingestion; Harmonization and Unification; Data Enhancements, Sharing, and Analysis; and Data Activations and Utilization. That coverage is exactly the plumbing a language-to-SQL project depends on, so a holder is likely to know the vocabulary. The certification was previously named Data Cloud Consultant, so older CVs and directory listings may carry the old title. Treat it as a floor. It does not demonstrate that the person has defined metrics for a finance team who argued about them.

The Agentforce credential, Salesforce Certified Agentforce Specialist, is a reasonable second item if the results will feed an agent. It covers Salesforce's agent features, not your warehouse.

#Where the data sits, and where permissions live

One design decision shapes cost, freshness and risk more than any other, and a good partner raises it in the first meeting: does the data get ingested into Data 360, or is it queried where it already sits? Ingesting gives you a copy that Salesforce can work on directly, at the price of storage, refresh schedules and a second set of permissions to maintain. Querying in place keeps one source of truth but ties every answer to the warehouse's speed, its compute bill and its own access rules. Neither is wrong. What is wrong is having nobody who can say which one the project chose, and therefore nobody who knows where a row-level restriction is actually enforced.

Ask the partner to draw the path of one question from the person asking to the table and back, marking the point where identity is checked. If the drawing shows a single service account running every query, the system is relying on whoever wrote the question box to filter the answers, and you should ask hard questions about that. A sturdier design carries the asker's identity, or a role that maps to it, all the way to the point where rows are filtered.

The same drawing exposes the Tableau question. The announcement tied Waii's graph to Tableau's next-generation semantic engine, so metric definitions written for this project may eventually serve analytics as well as chat. That is a reason to write them in plain business language and keep them in a place you control, rather than burying them in a tool-specific setup nobody can export.

#A realistic first engagement

Choose one question family that a named business owner cares about and can adjudicate, for example pipeline coverage or order backlog, and one schema that holds the source tables. The sequence I would expect from a sound partner:

1. Interview the owner and write down the five to ten questions they actually ask, in their words, together with the answer they currently trust and where it comes from.
2. Document the tables, the sanctioned joins, the metric definitions and any known traps, such as test accounts or cancelled orders that must be excluded.
3. Connect the schema through Data 360 and confirm the data arrives and unifies as expected.
4. Build the golden question set: the same questions, with known right answers, run as an executive, an analyst and a restricted user.
5. Review every wrong or missing answer with the owner. Some will be bad definitions, some bad data, some genuine system errors, and the partner should be able to tell which.
6. Agree a threshold for going live, such as every golden question correct for the user who should see it, and refusals for the user who should not.

Deliverables are the metric dictionary, the golden set with results, the permission log and a recommendation.

#Red flags specific to this product

• Demos on a clean sample dataset. Your warehouse has three tables called customers and two versions of the truth.
• A claim that the model "learns your schema" so no definition work is needed. A graph is only as good as the meaning someone gave it.
• No answer to the question of who owns the metric dictionary after go-live.
• Generated SQL that nobody on the team can read. Ask to see the query behind a result, and a plain-English explanation of why those joins.
• Testing as an administrator only. The row a narrow user must not see only appears in a test run as that user.
• Warehouse cost ignored. Language to SQL invites more queries, and every query spends compute on your warehouse platform.
• Treating the Data 360 rename as a project. It is a label change on the same product, and documentation or templates may still say Data Cloud.

#Ten questions for the interview or RFP

1. Show me a metric dictionary you wrote for a previous client, with the owners removed. How did you resolve two teams defining the same metric differently?
2. Which SQL dialects and warehouse platforms have you worked on, and which will our project use?
3. How will you build and keep the golden question set, and who adjudicates a disputed answer?
4. What will you do when a plain-language question is ambiguous? Refuse, ask back, or choose a default?
5. How does the design stop a narrow user receiving a row they should not see? Walk me through a test.
6. How will you control the warehouse compute that new questions generate?
7. What happens to our definitions when a source schema changes? Who finds out first?
8. Which parts of what Salesforce announced for Waii are generally available today, and how do you know?
9. Can the person asking see the generated SQL, and does your plan include a review step for new question types?
10. What is our exit position if we stop using the feature? Where do the definitions live, and can we keep them?

#References and evidence

Skip the logo slide and ask the reference to answer three narrow things. Did the partner agree metric definitions with the business before building? Were wrong answers found in testing, and how many were data problems rather than tool problems? Did a restricted user get refused in the final test? A reference who only says the team was helpful has told you nothing.

Ask the partner for the redacted golden-set results from a past project: the number of questions, how many were right first time, and what changed afterwards. Do not accept a success rate quoted without that detail. If a partner offers a headline accuracy figure for natural language to SQL, ask what questions were asked, against whose data, and who marked the answers.

#Commercial models and the statement of work

A fixed-scope discovery that ends in the metric dictionary and golden set is a sensible first purchase. It is cheap to stop after, and it exposes whether your data is ready. A second phase of build and rollout can then be priced from the actual list of tables and metrics. Avoid a single fixed price for a whole-warehouse rollout agreed before anyone has opened the schemas.

The statement of work should name the schema and tables in scope, the question family, the golden set size and the pass rule, the identities used for testing, the roles that sign off definitions, the warehouse cost monitoring the partner will set up, and the handover of the dictionary in a format you own. We have not quoted a services price. No citable source we found gives one, so compare quotes by their work packages and ask each firm to say what they assumed about the number of tables and metrics.

#When you can skip a partner

If you have a strong in-house analytics engineer, one well-documented schema, and an owner who can answer metric questions quickly, you can run a small pilot yourselves using Salesforce's documentation for Data 360. The balance tips towards a partner when several source systems must be unified, when finance and sales disagree on definitions, or when row-level restrictions are strict enough that a leak would be a notifiable incident.

Even if you do skip the partner, borrow their discipline. Write the questions and the trusted answers down before you switch anything on, name one person who may rule on a disputed definition, and keep a log of wrong answers with a note of why each was wrong. Teams that keep that log find within a month that most errors trace back to two or three ambiguous definitions, which is cheap to fix once you can see it and expensive to discover through a complaint from the finance director.

The build is described on Waii, plain-language SQL and Data 360. For the corporate facts see What happened to Waii, for the diagram see Integrating Waii with Salesforce, for the move question see Should I migrate from Waii, and for money see Waii Salesforce licence cost and Waii Salesforce implementation cost.