Integrating Doti with Salesforce

A platform owner hears that the Doti deal has closed and opens a ticket the same afternoon. The ticket says to connect every repository the company has, because search should now be able to answer from anywhere, and Slack is where people ask. The ticket has a date on it. It does not have an owner for each repository. It does not say what a reply is allowed to paste into a channel.

That ticket is the integration, started from the wrong end. The close is a fact about Salesforce and Doti. The integration is a fact about your estate: which system a reply reads, which file it may quote, and what happens when the person who asked cannot open that file.

This page is that choice, written down. The build of the search, including sources, identity, and refusals, is Doti, Slack, and enterprise search. What the close did and did not publish is What happened to Doti. Read those when you need the neighbouring question. Stay here when you need the three labels a diagram has to carry.

#What the cited page says

The sentence this page quotes is the completion record: "Salesforce completed its acquisition of Doti on December 1, 2025." Completed means the deal is done. The day, in the order this guide uses outside the quotation, is 1 December 2025.

Read the sentence for what it contains. A buyer. A company. A day. It does not name your repositories. It does not name a Slack workspace. It does not name a file. It does not say that a repository becomes connected because a contract between two companies was signed. If a steering slide treats the sentence as an instruction to connect sources, the slide has added a verb the record does not have.

The same sentence does not describe a screen, a daily limit, a price, or a connector you can install. This page will not supply those. A guide that invents them looks practical for a week and then fails the first question from security: where is that written. The answer would be "in our diagram", which is not a source.

Slack is the conversational interface. A person asks in Slack. Search does the finding. The interface is not a dump of every file. A channel can show a reply. A channel is not the place the file moved to. Hold that split before you draw anything. Teams lose it when they hear "Slack" and picture a folder. Slack, in this design, is where the question is typed and where an allowed answer may appear. The file remains in the system that already stored it.

#The system

The system is not one box. Two systems are in play, and they do different jobs.

The first is Slack, as the conversational interface. People already have rooms there. A public channel, a private channel, and a direct message are different rooms. A reply that is safe in one can be a publication in another. The integration has to say which rooms may receive an answer. "Slack" as a single word hides that choice. Write the room type down.

The second is the system that holds the file. A repository. A wiki. A contract store. A case in Salesforce. Each of those can be a source. Each remains the store. Search may read a source when two things are true: a named owner has agreed the source is in scope, and the identity used for the read can open only what the design allows. The close does not perform that agreement for you.

Do not connect every repository because the deal closed. A repository is connected when its owner says the search may read it, for a reason you can say in one sentence, under an identity you can name. "The deal closed" is not that sentence. It is true, and it is the wrong reason. Connecting a repository because it was easy to reach in a demonstration is the same mistake with a smaller audience. The demonstration ends. The connection remains.

Salesforce can be one source among others, because accounts and cases live there. That does not make Salesforce the place every file is copied into. Copying the text and dropping the grant that sat on the file gives you words nobody is allowed to trust. Leave the file where it is. Let the reply point at it, or quote it, only when the person who asked can open it themselves.

Name a human owner for the search identity as well. The identity is part of the system, because it is the ceiling on every read. If the identity can open a restricted repository, a reply can quote that repository into a room. Choose the identity the way you would choose access for a new starter. A token that was created so a workshop could see rows is a poor identity to leave in place on Monday.

#The object

The object is the file the answer quotes. Not the company. Not the channel. Not the acquisition. A file has a location, an owner, and a grant. The integration is about that file, one question at a time.

A link the person can open under their own login is one object. A pasted paragraph is another. They are easy to confuse because both can sit in a Slack thread and both can look helpful. They are not the same. A link sends the person back to the system that holds the file, and that system applies the grant again. A paste has already crossed the boundary. The thread now holds the words, including for people in the room who could not have opened the file.

Write the rule in a sentence a channel admin can apply. For a public channel, prefer a link, or a refusal, when the file is not open to everyone in the channel. For a private channel, still ask whether everyone in the channel can open the file. A private channel is a group. It is not a single person. A direct message can be forwarded. If the design assumes a direct message stays with one reader, say so, and say what you will do when it does not.

The object has a boundary around drafts as well. A file the author has not shared is not available merely because someone asked a fluent question. The question is a request. The grant is the decision. If you cannot explain the grant, you are not ready to let the reply include text. List sources by name. A short list you can defend is a better integration than a complete list you cannot explain.

#The failure

The failure is an answer that quotes a file the person cannot open. The search found something. The something was real. The person who asked, logging in as themselves, would have been stopped. The thread was not stopped. Colleagues read the extract. The file owner finds out from the thread.

That failure can happen on a small design. You do not need every repository connected to produce it. You need one restricted file, one broad identity, and one room that is larger than the grant. Connecting every repository makes the failure more likely, and makes the cleanup harder, because you will not know which source the sentence came from. It is not a required step, and it is not a sign of a mature integration. It is how the failure gets a wider surface.

Treat the failure as a test, not as a slogan. Pick a person. Pick a file that person cannot open. Ask, as that person, in a channel that matches the room you intend to use. The pass is dull. The reply does not contain the file's text. It may say the file is out of reach. It may offer nothing. It must not quote the file. If the only passing run used an administrator token, the test did not pass. Change the identity and run it again.

Write down what the reply should do instead. A pointer the person can try under their own login. A plain refusal. Silence is a poor third option if the person will simply ask again in a larger room. The substitute has to be decided before the first real question, because the helpful path is the one a keen user will take on a Friday.

Log the question, the source that was touched, and whether text came back. If you cannot read that log a month later, you cannot explain the failure to the person who owns the file. Logging is part of the integration. It is not a later tidy-up. A design that can quote a file and cannot say which file it quoted is already in the failure, even before anyone complains.

#The diagram

A diagram that does not name the system, the object, and the failure is a poster. It can be attractive. It cannot be built. Boxes labelled with a product name, and an arrow labelled "search", leave the three decisions blank. Someone will fill them in during a workshop with whatever is easiest to connect.

Put these three labels on the picture. If a label is blank, do not connect anything.

Read the table aloud in the design review. If someone adds a box for "all repositories", ask them to replace it with named stores and named owners. If they cannot, the box comes off. The deal is not an owner.

Keep the picture boring. You do not have a screen, from this source, to redraw. You do not have a connector name to put in a corner. A boring table that names the three labels will outlast a poster that implies a product module you were not shown.

#What you write before anyone connects a source

One page, in sentences. If a line is blank, the connection waits.

The rooms. Which Slack workspace, and which kinds of room may receive an answer. Public, private, and direct. Say whether the answer may include text, or only a link, or a refusal.

The stores. Each repository, wiki, or record system that is in scope, with a human owner. Stores that are out of scope, written down so a later ticket cannot add them "for completeness". Completeness is how every repository gets connected.

The identity. The account or token the read uses, and the person who owns it. What it must not open. Review it when that person leaves the organisation.

The object rule. A reply may quote a file only when the person who asked can open that file. Write the sentence. Then write the test that proves it, including the file you chose and the person you chose.

The log. Where the question, the source, and the fact of a quote are kept, and for how long. Name the person who can read the log when a file owner asks.

The stop. When the search cannot see an allowed file, it stops. It does not guess a clause from a title. A confident sentence is not a substitute for the file.

None of these lines is a price. This page does not have a price, a day rate, or a cap on questions per day. If a proposal opens with a fee and none of the lines above, send it back. The lines are the scope. A fee without them is a fee for a poster.

#How the other two pages fit

This page stops at the three labels and the rule that keeps a quote inside the grant. It does not retell the corporate story, and it does not try to be the whole build.

What happened to Doti is the page for the close itself. Who owns the company. The day. What was not published, including a price and a shutdown date. Send people there when the argument in the room is about the deal. Do not let that argument choose a repository.

Doti, Slack, and enterprise search is the page for the build. Sources, the identity as a ceiling, refusals, and what a quote should list before anyone talks about cost. Use it when the three labels on this page are accepted and the work turns into a list you can hand to a partner. If a partner has not read it, and still wants every repository in week one, they are building the failure. A question aimed at tables is a different grant. Leave it on its own page.

#A first week that can be reversed

Pick one store the owner already allows. Pick one room that matches how you will really work, not a private test channel that hides the publication problem. Pick one person, and one file that person cannot open. Run the question. Read the reply. If the file's text is in the reply, stop. Change the identity or the room. Do not add a second store to "see how it scales". Scale is how an unfixed failure spreads.

Write the result in the log, including the empty result. An empty result is a pass when the file was forbidden. Teams sometimes delete empty results because they look like the tool is broken. Keep them. They are the evidence the integration is doing the job.

At the end of the week you should be able to point at the diagram and fill every cell from notes, not from memory. System, object, failure. If you cannot, you are not ready for a second store. You are ready for another pass on the first one.