Integrating Waii with Salesforce

A finance analyst types a question on a Thursday and gets a row back. The row is from a table the data team closed to the business last quarter. The analyst did not ask to bypass anything. They asked a reasonable question about customers. The query ran with the rights it had, and the rights were wide, because a demonstration had needed rows. The row is now in a shared channel, in a screenshot, with the question above it.

That is the integration failing in one move. The close did not cause it. A missing decision caused it. The decision is which system the query may read, which row it may return, and what you do when the asker should not see that row. A polite question does not make the decision. You do, before the first real ask.

This page is those three labels. The wider build, including catalogue, grants, and refusals, is Waii, plain-language SQL, and the Data 360 rename. The corporate record, including what was not published, is What happened to Waii. Use those pages for their questions. Stay here until the diagram can name the system, the row, and the failure.

#What the cited pages say

Two sentences, from two pages, and this guide quotes each once.

The close notice says: "Salesforce completed its acquisition of Waii on August 15, 2025." The day, outside that quotation, is 15 August 2025. Completed means the deal is done. The sentence does not name your tables, your roles, or which colleague may ask. It does not say a question box appeared in every org on that morning. If someone briefs the room that it did, ask them to point at the sentence. They will not find the briefing there.

The help text says: "As of October 14, 2025, Data Cloud has been rebranded to Data 360." Put the current name on the diagram, in the statement of work, and in the note you give a new analyst. The rename is a name. It does not add a table, remove a grant, or decide that a question is allowed. Old labels may still appear while people and documents catch up. Your picture should not be one of the documents that stays on the old name out of habit.

Keep the two dates apart. The acquisition completed on 15 August 2025. The rename is dated 14 October 2025. A design written between those dates can be right about the intent and wrong about the label. Fix the label. Then read the grants again. They do not update themselves because a product changed its name.

Neither sentence sets a price, a daily cap, a connector name, or a screen. This page will not invent them. A picture of a settings panel you have not been shown is a guess. Security will ask where the panel is documented. "In the guide" is not an answer you can use.

#The system

The system is the place the query runs, under an identity, against tables you have named. A question is the way a person asks. It is not the system, and it is not permission to read every table.

Write the identity before anyone tries a question. For an analyst, that may be the role they already have in the warehouse tool, so they see what they already see. For a wider audience, a seller or a support lead, the role should be narrower. It can read the tables you listed and nothing beside them. "The integration user" is not a design. A role that can read every table is a design, and it is the wrong one if the audience is the whole company.

Name the tables. Each table has an owner. A table without an owner will be included because a demo needed a number, and it will still be included next year. The list can be short. Short and owned is the system. "All customer data" is a poster caption.

Data 360 is the name on the Salesforce side of the picture after 14 October 2025. Use it. Do not let the new name become an excuse to draw every schema you can find. A slide that says Data 360 and then shows the whole warehouse has used a correct word to hide an old mistake. The word is the easy part. The list of tables is the system.

Salesforce objects you already administer, such as accounts, are not automatically part of that list. Add one when its owner agrees, for a reason you can say in a sentence. Leave it off when you cannot say the reason. The acquisition does not perform the agreement.

#The object

The object is the row the query returns. A question can sound like a request for a summary. The warehouse still returns rows, or numbers built from rows. Treat the row as the thing you are allowing into the room.

Keep the query beside the row. A row on its own cannot tell you which table was read. The query can. If the path returns a figure and withholds the query, you cannot tell whether it read the closed table, the approved set, or both. Store them together, under the same retention rule. A reviewer who cannot read the query cannot approve the row.

A question is not permission to read every table. Say that in the design review until it is dull. People skip it because the interface is polite. The analyst asked for customers and spend. The tool did what a query path does: it ran with the rights it had. Helpfulness is not a grant. The grant was whatever the identity could select. If you wanted the table closed, close it on the identity. Do not close it by hoping the question will be modest.

The object has an audience as well. A row shown to the asker, on their own screen, under their own role, is a smaller publication than a row pasted into a channel. Decide which of those you are building. If you are building both, say so as two rules. One rule does not imply the other. A personal answer that later gets forwarded has become the channel. Write what the asker is allowed to forward, or accept that you cannot stop a forward and keep the row dull enough to survive one.

There is no object called "whatever the question needs". That phrase lets the identity grow until the failure is easy. The object is a row from a named table, returned to a named kind of person.

#The failure

The failure is a query that returns a row the asker should not see. The row can be accurate. Accuracy is not the test. The test is whether that person was allowed to see it. A correct row in the wrong hands is the failure this integration exists to prevent.

It happens in ordinary ways. The identity was copied from an administrator so the pilot would not look empty. The table was added because one executive asked once. The result was pasted because the channel is where the team shares numbers. None of those steps looks like an attack. Together they are the failure.

Make it a test. Pick a person who must not see a chosen table. Ask, as that person, a question that would return a row from that table if the identity were too wide. The pass is an empty result, or a refusal, with no row. If you only ran the test as an administrator, you tested the wrong person. Run it again as the asker you actually intend.

Write the refusal in plain language. No table in scope. No grant. No confident match. A sentence that guesses the figure is not a refusal. It is the failure wearing a helpful tone. Teams accept guesses because a blank looks like the tool is down. A blank, in this test, is the tool working.

When the failure has already happened, the log is how you explain it. Who asked. Which query ran. Which table was touched. Whether a row came back. If you cannot answer those a month later, you cannot sit with the data owner and show your work. Build the log before the pilot, not after the screenshot.

#The diagram

A diagram that does not name the system, the object, and the failure is a poster. An arrow from "question" to "insight" will be admired and then implemented as every table. Put the three labels on the page you will actually build from.

If a box on the picture says "all tables", replace it with the list, or remove the box. If the picture still says Data Cloud and the date is after 14 October 2025, change the words before you argue about access. Fixing the name is not finishing the design. Leaving the old name is how two workstreams brief past each other.

This source does not give you a screen to trace, a connector name to drop in the corner, or a cap on questions per day. Do not draw those. A table with three filled labels is the diagram. A cloud shape with a logo is the poster.

#What you write before a query is allowed

One page. Blank lines wait.

The identity. Who it represents, who owns it, and three tables it must not read. Review it when the owner changes role.

The tables. In scope, with owners. Out of scope, so a later request cannot add them because a meeting was keen.

The audience. Who may ask, and where the row may appear. A personal screen and a shared channel are different publications.

The object rule. The query is stored with the row. A row without a query is not accepted.

The refusal test. One question that must return no row from a closed table, run as the real asker, with the result kept.

The rename. The diagram, the statement of work, and the analyst note say Data 360. Someone is named to correct old labels when they show up in a pack.

No price belongs on this page. The cited sentences do not carry one. A proposal that leads with a fee and a promise that any colleague may ask anything has skipped the list. The list is the integration. The promise is the failure, sold in advance.

#How the other two pages fit

This page stops at the three labels. It does not try to be the whole implementation, and it does not retell the acquisition.

What happened to Waii answers the close, the owner, and what the record does not contain. Send the room there when the debate is about the deal, the date, or a figure that never appeared. Do not let that debate add a table.

Waii, plain-language SQL, and the Data 360 rename is the build. Catalogue, grants, saved questions if you have them, and what a quote should include. Go there when these three labels are accepted and you are ready to scope work a partner can price. A partner who has not read it, and who still offers every table to every asker, is pricing the failure.

Search across files, with Slack as the place a person asks, is a different boundary. Do not merge the two into one "data access" box. The file side has its own diagram.

#A first question you can defend

Choose one approved table. Choose one closed table. Choose one person who may see the first and must not see the second. Ask two questions, as that person, with the identity you intend to keep. The first may return a row. The second must not.

Read both queries, not only the rows. If the second query names the closed table, the test has failed even when the result looks empty, because the path still reached for it. Tighten the identity until the closed table is not in reach. Then write the result down.

Do not add a third table in the same week to show progress. Progress here is a pair of results you can explain to the table owner. When you can fill the diagram from those notes, you have an integration. When you can only fill it from the acquisition date, you have a poster.