Enterprise Search Cost: Connectors, Permissions and Relevance

Enterprise search projects budget for a search platform and spend their effort on connectors and permissions. Each source system is a separate integration with its own quirks, and getting permissions right across all of them is both the hardest requirement and the one where failure is a security incident rather than a quality issue. This guide covers the real drivers, drawing on FISTA Solutions' AI agents delivery. It complements knowledge base cost and what is metadata filtering in rag.

Why are connectors the main cost?

Because each source is a separate integration. Different APIs, authentication mechanisms, content formats, permission models, pagination behaviour, rate limits, and change notification approaches.

Ten sources is ten integrations, each requiring initial build and ongoing maintenance as the source system changes underneath. That maintenance is continuous and is the cost most often omitted from a business case that counts sources as a scope item rather than as a recurring obligation.

Source characteristic	Effect on cost	Notes
API quality and documentation	Large	Determines build effort
Permission model complexity	Large	Hardest part
Change notification support	Moderate	Polling is expensive
Content format variety	Moderate	Extraction effort
Volume and update rate	Moderate	Indexing cost
Vendor API stability	Recurring	Maintenance burden

Why are permissions so hard?

Because they must be accurate, current, and evaluated before search rather than after. Each source has its own model — groups, roles, inherited folder permissions, per-item sharing, external collaborators — and they must all be mapped into a form the search index can filter on.

Permissions also change constantly as people join, leave, and move. A synchronisation that runs nightly means a full day during which someone may see content they no longer should.

What happens when permissions are stale?

Disclosure. A user sees content from a project they left, a salary review they should not see, or a document shared with a group they were removed from.

That is a security incident rather than a search quality issue, and it is the failure mode that ends enterprise search deployments. It is also why filtering must happen before search rather than after: post-filtering leaks through result counts, previews, and summaries. See ai access control.

Why is relevance tuning continuous?

Because what people search for changes, the content changes, and initial relevance is always imperfect. Tuning based on behaviour — what was clicked, what was refined, what was abandoned — is what closes the gap.

That work is ongoing rather than a launch activity, and it needs someone assigned. Search that is not tuned degrades relative to changing content and usage, and users notice before anyone measures it.

What determines adoption?

The first few searches. A user whose initial queries return nothing useful concludes the system does not work and does not come back, whatever it becomes later.

That makes launch relevance disproportionately important, and it argues for launching with a smaller, well-tuned set of sources rather than everything indexed and poorly ranked. A narrow search that works beats a comprehensive one that does not.

What about content that should not be indexed?

More than expected. Draft documents, personal files, superseded versions, and material with restricted handling all sit in sources that are otherwise appropriate to index.

Deciding what is in scope, and implementing exclusions reliably, is part of the build rather than a refinement, because the alternative is discovering that a sensitive folder was indexed after someone found it.

How should the programme be sequenced?

By source value. Index the two or three sources that hold what people actually search for, tune relevance until those searches succeed, and expand from there. That produces adoption early and builds the permission and relevance machinery on a manageable scope.

What should you do first?

Ask twenty people what they last failed to find and where it was. The answers concentrate in a small number of sources, and those are the ones to start with rather than the ones that are easiest to connect.

How does an AI answering layer change the calculation?

It raises the stakes on everything underneath. A search result list that includes a document the user should not see is bad; an answer synthesised from that document and presented confidently is worse, because the content has been read and repeated rather than merely listed.

It also raises the relevance requirement. A search returning ten results lets a user pick; an answering layer picks for them, which means retrieval errors become answer errors rather than results to scroll past. Both are arguments for getting permissions and relevance right before adding generation on top.

What is the ongoing operating cost?

Connector maintenance as source APIs change, permission synchronisation running continuously, index updates, relevance tuning, and the capacity to investigate when someone reports a wrong or missing result. Those are recurring and they scale with source count, which is the strongest argument for indexing fewer sources well.

How FISTA Solutions helps

FISTA Solutions builds enterprise search with permissions synchronised and evaluated before search, connectors prioritised by where people actually look, relevance tuned from behaviour on an ongoing basis, explicit exclusion of out-of-scope content, and launch scoped narrowly enough that early searches succeed, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To build search people use rather than search that indexes everything, message FISTA on WhatsApp, or read knowledge base cost.