# Who to hire for Doti on Salesforce There is no Doti product to buy a rollout of. What you hire for is Slack enterprise search, and the test of a partner is how they handle permissions. **Published:** 2026-08-11 **Canonical:** https://synconai.com/hire-doti-salesforce-partner **Author:** SynconAI Architecture Team ## In short Hire for what Doti became, not for a product called Doti. Salesforce completed the acquisition on 1 December 2025, and doti.ai now redirects to Slack. The work you can commission today is Slack enterprise search: connectors, org-level enablement, custom sources and permission testing. Ask for a Slack Administrator certification and evidence that replies respect each asker's access. ## Sources - **Salesforce Signs Definitive Agreement to Acquire Doti** (retrieved 2025-12-01) https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-doti/ > Salesforce completed its acquisition of Doti on December 1, 2025. - **Slack enterprise search connectors and software** (retrieved 2026-10-13) https://slack.com/features/enterprise-search > You can connect to home-grown systems, self-hosted software, and proprietary knowledge bases using the custom connector API. - **End user access control (Slack developer docs)** (retrieved 2026-10-13) https://docs.slack.dev/enterprise-search/enterprise-search-access-control/ > 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. - **Enterprise Search for apps (Slack developer docs)** (retrieved 2026-10-13) https://docs.slack.dev/enterprise-search/ > Note that apps containing Enterprise Search cannot be distributed publicly or submitted to the Slack Marketplace. - **Salesforce Certified Slack Administrator** (retrieved 2026-10-13) https://trailhead.salesforce.com/credentials/slackadministrator > Preparing to take the Slack Administrator exam? Check out this trail. ## What to take away - Doti is no longer a stand-alone product you can buy. The work to hire for is Slack enterprise search and the connectors behind it. - The decisive skill is permission testing: a reply must only draw on what the person asking could open themselves. - Ask for one named Slack Administrator and one named connector developer, not a logo slide. - A small pilot with two sources and a written refusal rule is a sensible first engagement. Connecting everything at once is the red flag. ## The guide 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](https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-doti/) 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. | Work package | What it involves | Who should own it | | --- | --- | --- | | Source selection | Choosing the two or three systems whose content staff actually search for, and writing down the ones left out | A business owner, not the partner | | Connector enablement | Installing and enabling search apps at org level, then switching them on for named user groups | Slack org admin | | Custom source build | Using the custom connector API for a wiki, a self-hosted tool or a knowledge base that has no ready-made connector | A developer with Slack app experience | | Permission and refusal testing | Proving a reply never draws on content the asker cannot open, and that an unreachable source produces a refusal, not a guess | A tester independent of the builder | 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. :::warn Do not hire anyone to "implement Doti". Hire a named Slack administrator and a connector developer, give them two sources, and make the refusal rule part of the acceptance criteria. ::: For the build itself, see [Doti, Slack and enterprise search](/doti-slack-enterprise-search). The corporate facts are on [What happened to Doti](/what-happened-to-doti), the system diagram is on [Integrating Doti with Salesforce](/integrating-doti-with-salesforce), the question of a move is on [Should I migrate from Doti](/should-i-migrate-from-doti), and the money questions are on [Doti Salesforce licence cost](/doti-salesforce-licence-cost) and [Doti Salesforce implementation cost](/doti-salesforce-implementation-cost). ## Questions ### Is there a Doti product we can ask a partner to implement? Not that we could verify. Salesforce completed the Doti acquisition on 1 December 2025, doti.ai redirects to Slack, and the announcement describes a unified search layer with Slack as the conversational interface. The work you can commission is Slack enterprise search and its connectors. ### Which certification should the lead have? Salesforce Certified Slack Administrator is the closest match for enabling search apps and managing org-level settings. Add a developer with Slack app experience for custom sources, and a Salesforce administrator or consultant if Salesforce records are one of the sources. ### What is the biggest risk when a partner connects sources? A reply that quotes content the person asking could not open themselves. Slack describes enterprise search as federated and permission-aware, so the risk lives in connector setup and testing. Insist on tests run as a restricted user, not as an administrator. ### Can a custom internal system be searched from Slack? Yes. Slack documents a custom connector API for home-grown systems, self-hosted software and proprietary knowledge bases. Slack's developer notes add that apps using Enterprise Search cannot go on the Slack Marketplace, so your organisation owns and maintains the app. ### When can we skip a partner? When you need one ready-made connector for one system and a pilot group, and you already have a Slack org admin. Bring in a partner for custom sources, sensitive content such as legal or HR files, or groups that need different results from the same system. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Agentforce consulting (https://synconai.com/salesforce-agentforce-consulting).