Slack Enterprise Search connectors and pricing: what Slack AI enterprise search actually covers

Slack enterprise search is a feature that extends Slack's search bar beyond Slack itself, so one query returns messages, files and canvases alongside content from connected third-party apps. Slack describes it as making "all your conversations, data, and third-party apps searchable from a single, AI-powered search bar", with results that are permission-aware and personalized to the person searching.

The architecture matters more than the marketing. Slack runs this as federated search: rather than copying your Google Drive and Confluence into a separate index, it queries those systems in real time and evaluates your access on each query. Slack states that customer data never leaves its trust boundary and that if your access to that data changes, the information stays secure.

The practical consequence of federation is that freshness is excellent and there is no re-index lag, but ranking across very different systems is harder than it is with a unified index, because the search engine has less control over how each source scores and returns results. Neither approach is simply better. They fail in different places, and the difference shows up on broad questions that span four systems rather than on lookups you already know the answer to.

Enterprise+. Slack's help documentation states that enterprise search is "Available on the Enterprise+ plan" and "Available on the Enterprise Grid plan with the legacy Slack AI add-on". There is no route to it from Free, Pro or Business+.

This is where most of the confusion in second-hand coverage comes from. Business+ does include a set of AI features that Slack labels Advanced AI, and those include an AI search experience inside Slack. That is not the same product. Enterprise search, meaning search that reaches into Google Drive, Salesforce, Confluence and the rest, appears only on the Enterprise+ row of Slack's pricing table.

Two administrative details catch teams out after the contract is signed. The feature is disabled by default for most organizations, so nothing happens until someone turns it on. And only Org Owners and Org Admins can enable, disable or configure it, which means a workspace admin cannot do it and a team lead certainly cannot. Budget a conversation with whoever holds org-level rights before you promise a rollout date.

Slack does not publish a price. Enterprise search requires Enterprise+, and the Enterprise+ column on slack.com/pricing reads "Contact sales for pricing" rather than showing a figure. Any specific dollar number you find for Enterprise+ is a reported or negotiated figure from a third party, not a Slack list price, and it should be treated that way.

We are deliberately not publishing an Enterprise+ number here. Third-party procurement datasets do report ranges, and those ranges are useful as a negotiating anchor, but quoting them as though they were Slack's price is how the Business+ myth started. What you can rely on is the shape of the cost: it is a per-seat uplift applied to your whole organization, not a per-seat add-on for the subset of people who need search.

That last point is the one to model. If 60 people in a 900-person company have the cross-app search problem, an Enterprise+ migration prices all 900. A tool priced per seat for the people who use it will often be cheaper even at a higher per-seat rate, and that arithmetic, not feature parity, is what usually decides this comparison.

Twelve, as documented by Slack: Asana, Box, Confluence Cloud, Dropbox, GitHub, Google Drive, Google Mail, Jira Cloud, Microsoft Outlook, Microsoft Teams, OneDrive and SharePoint, and Salesforce. Salesforce becomes available automatically if you have already connected it to Slack, which is unsurprising given both are Salesforce products.

Three caps are worth writing down before you scope a rollout, because they are documented but rarely mentioned in reviews. GitHub allows up to five organizations. Confluence Cloud supports a maximum of five subdomains. Jira Cloud supports a maximum of five subdomains. Any company that has grown by acquisition, or that spun up separate Atlassian sites per business unit, should count its subdomains before assuming full coverage.

Note also a discrepancy worth checking against your own account. Slack's marketing page for the feature names Notion among the supported apps, while the help article that lists connectors for setup does not. We have not been able to reconcile that from public documentation, so if Notion is where your specifications and project docs live, confirm it directly with Slack rather than taking either page at face value. Teams in that position often end up covering it with Notion workspace search instead.

Since January 28, 2026 you can also build your own. Slack's Search Custom Connectors API, built on the Slack platform and Bolt SDKs, lets you surface an internal system alongside native results. It requires Enterprise+ as well, and it requires engineering time: you are writing and maintaining the integration, including the authentication flow that keeps results scoped to the right user.

An Org Owner or Org Admin turns it on from the organization settings, then connects each source individually. Enterprise search is disabled by default for most organizations, so a fresh Enterprise+ contract does not mean the feature is live.

Each connector is its own configuration step rather than a single switch. Some sources need extra information before they will connect: GitHub wants the organization names, and Confluence Cloud and Jira Cloud want the subdomains, which is where the five-item caps bite. Admins can also control whether connected content appears in traditional search results, in AI answers, or in both, which is a genuinely useful control if you want to phase a rollout rather than change everyone's search results overnight.

The step teams skip is deciding what should not be connected at all. Shared drives holding HR case files, legal matters under hold, and unredacted customer data are usually excluded by policy rather than by permission, because permissions alone will not stop a document that was over-shared three years ago from surfacing. Draw that line before the first connector goes live, not after somebody finds something in a search result.

Yes, and this is one of the areas where Slack's implementation is genuinely strong, so it is not a useful place to attack it. Slack's documentation states that "Search results, AI answers, and Slackbot responses will only include source content that the person searching has permission to access."

Because the search is federated, access is evaluated at query time against the source system rather than against a permissions snapshot copied during an overnight sync. That closes the revocation window that catches out products which sync access control lists on a schedule: when someone leaves a project, or a document is locked down, the change takes effect on the next query rather than on the next sync. Slack's own phrasing is that if your access to that data changes, the information stays secure.

The question worth asking a vendor is not whether they support permissions, since almost everyone claims to, but when they check them. Query time is the right answer. A nightly or hourly access sync means there is a window during which revoked access still returns results, and the length of that window is a security property you are buying. We take the same approach and explain it in more detail on secure enterprise AI search.

Four, in the order they usually matter. First, the plan gate: Enterprise+ only, with no published price, so the cost of access is unknown until you have had a sales conversation and it applies to every seat in the organization rather than to the people who need search.

Second, the connector list. Twelve named sources is respectable, but it is finite and it is weighted toward the biggest platforms. Help desks, HR systems, data warehouses, internal wikis that are not Confluence, and homegrown tools are not on it. The custom connector API closes that gap only if you are prepared to own an integration as a piece of engineering.

Third, the per-connector caps: five GitHub organizations, five Confluence Cloud subdomains, five Jira Cloud subdomains. These are fine for a single-site company and a real constraint for a group that has acquired its way to eight Atlassian instances.

Fourth, and most decisive in practice, the surface. Everything here is reachable from the Slack search bar. If your company genuinely runs on Slack, that is an advantage, because the answer arrives where the conversation already is. If a large share of your people are in Microsoft Teams, or if the roles with the worst search problem work in a help desk or a browser all day, then buying an organization-wide plan upgrade to put answers in a client those people do not use is an expensive way to solve the wrong half of the problem. That is the case where unified search across every app, reachable from anywhere, does the job Slack cannot.

The honest split is about who works where, and about how many people you have to pay for. Slack enterprise search is the better answer when Slack is unambiguously your company's workplace, when your sources are all on the supported list, and when you were heading to Enterprise+ anyway for compliance or administrative reasons. In that situation you are getting search as a bundled benefit of a plan you already needed, and paying separately for a second tool would be waste.

A dedicated tool is the better answer in three fairly common situations. When your knowledge lives in systems Slack does not connect to, because coverage is the whole game and a search tool that cannot see the answer is not a search tool. When only a subset of the company has the problem, because an organization-wide plan migration to serve 60 people is poor arithmetic. And when the people who need answers are not in Slack: support agents in a help desk, new hires in a browser, finance in a spreadsheet, field staff on a phone.

There is a third possibility worth naming, which is that both are correct. Some companies keep Slack enterprise search for in-flow lookups and run a dedicated index for the deeper cross-system questions and for the teams outside Slack. That is not a hedge, it is two different jobs, and the cost only makes sense if you have genuinely counted how many people fall in each group. If you are at the shortlist stage, the sixteen-product table on enterprise search tools is the fastest way to see who covers which sources, and internal search covers the broader problem of answers that are documented but unfindable.