Who to hire for Doti on Salesforce

If you type doti.ai into a browser today, you land on Slack. The curl trail is short and dull: a permanent redirect to slack.com, then a regional redirect to a Slack page. That tells you something useful before you read a single proposal. Doti was an agentic enterprise search company, Salesforce said the team would strengthen its AI research hub in Israel, and the product's future is inside Slack rather than on a price list of its own. The announcement said as much: "With Slack as the conversational interface for this new capability, Salesforce will empower humans and AI agents to collaborate as teammates." So the question "who do I hire for Doti" is really "who do I hire to make search across our systems work inside Slack, safely".

Salesforce completed its acquisition of Doti on December 1, 2025. That sentence is the only dated fact the acquisition gives you, and it is the right place to stop treating the deal as a scope. The announcement describes a direction, "a unified, agentic search layer across the platform", not a connector you can install on Monday. We could not verify a generally available Salesforce product that carries the Doti name, so this page covers the work you can actually commission now and say so plainly.

#What you are really hiring for

Slack documents its enterprise search as federated: the question goes out in real time to connected systems, and results come back according to what the person asking is allowed to see. Slack's own help material says the same thing in plainer words: You can connect to home-grown systems, self-hosted software, and proprietary knowledge bases using the custom connector API. Two details in that documentation matter to a buyer. First, Slack's developer notes say Even after apps that use Enterprise Search features are installed and configured at the org level, they will not be available to end users by default. In other words, an org admin has to switch each search app on for users deliberately. Second, the developer documentation adds a limit that shapes the build: "Note that apps containing Enterprise Search cannot be distributed publicly or submitted to the Slack Marketplace." A custom source is therefore an internal app your own organisation installs, not something you pick off a shelf.

That produces four real work packages, and a credible partner can name them without prompting.

Notice what is absent: "migrate documents into Slack". Federated search leaves the document where it lives. A partner who proposes copying repositories into a Slack channel so search has something to find has described a different, riskier project.

#Skills and certifications that matter here

The credential that maps directly is Salesforce Certified Slack Administrator. Trailhead's page for it says: "Preparing to take the Slack Administrator exam? Check out this trail." Treat it as evidence that someone understands Slack's admin model: org-level app approval, workspace membership, and the difference between an owner and an integrations admin. It does not prove they can build a connector. For that, ask for a developer who has shipped a Slack app, and ask to read its manifest and scopes.

If the work also touches Salesforce records, such as accounts and cases appearing in search, you want someone who understands Salesforce sharing, because the same principle applies: the identity doing the reading decides what comes back. A Salesforce Certified Platform Administrator or a Sales or Service consultant credential on that person is reasonable. If agents will answer questions using the results, add Salesforce Certified Agentforce Specialist to the wish list, with the caveat that the exam tests Salesforce's agent features and not your Slack estate.

Be wary of the converse: a team with an impressive set of Agentforce badges and nobody who has ever opened Slack's admin console. Search quality problems in this area are overwhelmingly about connection and permission, not prompting.

#A realistic first engagement

The shape that works is deliberately small. Pick two sources that staff already complain about, say a policy wiki and a contract store, and one audience, say the legal and sales operations groups. The engagement then runs through five steps.

1. Confirm the Slack plan and admin settings allow enterprise search at all, and that the right people hold the admin roles.
2. Enable the two connectors for the pilot audience only.
3. Write the refusal rule in one paragraph: what a reply does when the asker cannot open the source file, and what it does when a connector is down.
4. Test with real people. One person with broad access, one with narrow access, and one contractor with almost none, each asking the same ten questions.
5. Review the results with the source owners before anyone else is switched on.

The deliverables are a short design note, the enabled connectors, the test log and a go or no-go recommendation. If the partner's plan has more than that in the first phase, ask what they are adding and why.

#Red flags specific to this product

Because Doti has no product page of its own, vague proposals are easy to write. The warning signs I would act on:

• A statement of work titled "Doti implementation". There is nothing called that to implement; the title is a search keyword.
• A diagram with every repository in the company drawn as an arrow into Slack. Completeness is how restricted files end up quoted in a public channel.
• A demonstration run under an administrator login. A demo only counts if the same question was tried as a restricted user.
• No named owner for each source. If nobody on your side can say yes or no to a source, the partner will decide by convenience.
• Promises about answer quality made before connectors are enabled. Quality depends on the sources and on what staff actually ask.
• A claim to be the official Doti team. Salesforce bought the company; a partner is a separate organisation, and you can ask Salesforce which services engagement you are actually dealing with.

#Ten questions for the interview or RFP

1. Which Slack plan is our workspace on, and what does that plan allow for enterprise search?
2. Who will enable each search app at org level, and who will switch it on for end users?
3. Show me the permission test log from your last search project. Which restricted user asked which question?
4. For a source with no ready-made connector, how would you use the custom connector API, and who maintains the app afterwards?
5. What do replies do when the source is unavailable or the asker lacks access? Show me a real example of the refusal.
6. Which source would you advise leaving out of phase one, and why?
7. How do you handle a person whose access changes the day after a successful query?
8. What happens to our search apps if the partner relationship ends? Who holds the app credentials?
9. How will you measure whether staff are finding what they need, using something other than a demo?
10. Which parts of the work do you expect us to do, such as source owner sign-off and test participants?

#What happens after the pilot

Most search projects are judged six months later, not on launch day, so ask what the partner hands over. A connector is a living thing. Credentials expire or are rotated, a source system changes its structure, an owner leaves and nobody remembers why a folder was excluded. The handover pack should therefore include a register of connected sources with their owners, a list of the groups each connector is switched on for, the steps to disable a connector quickly if a source owner raises a concern, and a plain-language record of what was tested and when.

Agree a review rhythm too. A quarterly look at who can use each search app is cheap, and it catches the contractor who finished in March and still appears in a group. Adding a third source should repeat the same five steps as the first two, including a fresh permission test, because a new source brings a new permission model. A partner who treats later sources as a copy-and-paste exercise is the one most likely to produce the awkward thread where a colleague quotes something they should never have seen.

#References and evidence that do not rely on logos

A logo tells you a customer existed. Ask instead for a reference who can answer three narrow questions: did the partner write a refusal rule before they connected anything, did they test as a restricted user, and did the source owners sign off before launch. Ask the reference to name the people involved by role, not to praise the team. Ask the partner for a sanitised copy of a permission test plan from a previous engagement, with customer details removed. If they cannot produce one, they have probably never written one.

Slack's trailhead credential is checkable. Ask for the Trailhead profile link or the credential verification, and match the name to the person who will actually attend your meetings.

#Commercial models and what goes in the statement of work

A fixed-scope pilot suits the first phase, because the scope is two sources and one audience and the finish line is a test log. A time-and-materials arrangement with a cap suits a later phase where unknown sources keep appearing. Avoid any arrangement that pays on connectors enabled, since the incentive is more connectors, which is the failure you are trying to avoid.

The statement of work should contain:

• The named sources in scope and the named sources out of scope.
• The audience groups switched on, and the date they are switched on.
• The refusal rule, quoted in full.
• Who owns each app credential, and how the credentials are handed over.
• The permission test plan, with the minimum number of restricted-user cases.
• Acceptance criteria written as behaviours: a restricted user asking for a restricted file receives a refusal or a link to try under their own login, never an extract.
• Out-of-scope items, including content migration and any custom development beyond the named sources.

We have deliberately left pricing out. This page makes no estimate of services cost because no citable source gives one for Slack search work; ask for the quote built from the work packages above and compare it line by line.

#When you can skip a partner

If your workspace is on a plan that includes enterprise search, you have a Slack org admin, and you want one ready-made connector for one system, a competent admin can follow Slack's documentation and enable it for a pilot group. That is an afternoon of reading and a careful test. The case for a partner begins when you need a custom source, when sources include sensitive material such as legal or HR files, or when different groups must see different results from the same system. At that point the permission testing is the job, and an independent pair of eyes is worth having.

For the build itself, see Doti, Slack and enterprise search. The corporate facts are on What happened to Doti, the system diagram is on Integrating Doti with Salesforce, the question of a move is on Should I migrate from Doti, and the money questions are on Doti Salesforce licence cost and Doti Salesforce implementation cost.