Connecting RAG to Enterprise Knowledge: SharePoint, Confluence, Slack, and the Connector Layer

The part of an enterprise RAG program that decides its fate is not the embedding model or the vector database — it is the connector layer that moves knowledge out of SharePoint, Confluence, Google Drive, and Slack and keeps it current, permission-correct, and complete. Managed connectors from AWS, Microsoft, and Google cover the common cases; their documented limitations define exactly where you will have to build.

1. By the numbers

2. Why the connector layer decides the outcome

Every RAG tutorial starts the same way: documents in a bucket, a chunker, an embedding model, a vector store. Every enterprise deployment starts differently: the knowledge a pilot needs is scattered across SharePoint sites with item-level permissions, Confluence spaces full of half-maintained pages and attachments, Drive folders shared ad hoc, and Slack threads where the real decision was actually recorded. The bucket-first demo works precisely because it skips the three problems that dominate production: getting content out of systems of engagement, keeping it synchronized as those systems change, and carrying each document's access rights along with its text.

That reframes the buying decision. When you evaluate a RAG platform — a hyperscaler knowledge base, an enterprise search suite, or a build-your-own stack — the connector catalog and its fine print matter more than retrieval benchmarks, because a retrieval system that cannot reach 60 percent of your corpus, or reaches it with stale permissions, fails no matter how well it ranks. The questions to put to any vendor are concrete: which of our systems do you connect to, is the connector GA or preview, how do you detect changes and deletions, and how do you enforce our ACLs at query time.

3. What the three hyperscalers actually ship

AWS splits Amazon Bedrock Knowledge Bases into two modes, and the connector story differs sharply between them. For the managed mode, the documentation states verbatim: "Managed Knowledge offers connectors for Amazon S3, SharePoint, Confluence, Google Drive, OneDrive, Web Crawler, along with document-level permission filtering using Access Control Lists (except for Web Crawler) at retrieval time."^[1] The customer-managed mode — where you run your own vector store — carries a pointed caveat: "several capabilities such as third-party connectors, document-level permissions and native AgentCore Gateway integration are only available for Managed Knowledge Bases."^[1] In other words, AWS ties its best connector and permission features to the mode where it also controls ingestion, indexing, and storage.

The fine print on the individual Bedrock connectors matters just as much. Both the Confluence and SharePoint data source connectors are marked "in preview release and … subject to change," support only the cloud editions (Confluence Cloud and SharePoint Online), and "don't support multimodal data, such as tables, charts, diagrams, or other images"^[4][5] — multimodal content is only supported through Amazon S3 and custom data sources, and other source types skip those files during ingestion.^[6] Both connectors also currently work only with the Amazon OpenSearch Serverless vector store, and the SharePoint connector cannot crawl OneNote documents.^[5]

Microsoft's equivalent for custom RAG is the Azure AI Search SharePoint indexer, and its status line deserves quoting in full: "The SharePoint in Microsoft 365 indexer is in preview. It's offered 'as-is' … and supported on a best-effort basis only. Preview features aren't recommended for production workloads and aren't guaranteed to become generally available."^[3] The indexer does real work — incremental indexing of files, lists, and site pages, automatic deletion detection, and ACL ingestion — but list, page, and ACL support are themselves flagged as preview inside the preview, and the limitations section states "Limited support for document-level access permissions. A basic level of ACL sync is currently in preview."^[3] Notably, Microsoft's own guidance for production RAG over SharePoint points elsewhere: to the remote SharePoint knowledge source built on the Copilot Retrieval API, which queries SharePoint directly so that "Azure AI Search doesn't replicate data" and the SharePoint permission model is enforced at query time, or to building a custom pipeline with SharePoint webhooks, Microsoft Graph, and the blob indexer.^[3]

Google has consolidated its Vertex AI Search and Agentspace connector catalog under Gemini Enterprise, and it is the broadest of the three for third-party sources: Box, Confluence (Cloud and Data Center), Dropbox, GitHub, HubSpot, Jira (Cloud and Data Center), Microsoft Entra ID, Outlook, Teams, OneDrive, SharePoint, ServiceNow, and Slack are listed as generally available, with Salesforce in public preview.^[7] Each connection creates a data store with per-entity stores for the content types you select — "Jira Cloud has entities such as issues, attachments, comments, and worklogs"^[2] — which is the right abstraction for sources whose knowledge is not shaped like documents. The tradeoff is that this catalog is attached to Google's search-and-assistant product surface, not to an arbitrary pipeline you compose yourself.

4. Permission-aware retrieval is the hard problem

Copying documents is easy; copying who may read them is not. The moment a connector replicates content into a search index or vector store, the source system's permission model stops protecting it — protection now depends on the pipeline having captured ACLs correctly at ingestion and enforcing them at query time. AWS states the failure mode plainly for its customer-managed connectors: "All data that you sync from your data source becomes available to anyone with bedrock:Retrieve permissions to retrieve the data. This can also include any data with controlled data source permissions."^[5] Fine-grained SharePoint or Confluence permissions flatten to a single API-level yes/no unless you use the managed tier's document-level ACL filtering or build trimming yourself.

Even when ACLs are ingested, they lag. Azure's preview terms acknowledge this directly: with access- or permission-restricted content, "a timing lag occurs before the 2026-05-01-preview recognizes changes to those access or permission restrictions."^[3] Google's model makes the same physics visible in scheduling: identity data — the mapping of users to ACL groups — is refreshed by syncs whose fastest full cadence is every 3 hours.^[2] The practical consequence: when someone is removed from a SharePoint site or an HR space is restricted after a sensitive announcement, there is a window in which the index still believes the old permissions. Your security review should ask for that window's size and decide which sources can tolerate it; for some — M&A folders, HR investigations — the honest answer is that they should never enter a replicated index at all, or should be reached only through query-time APIs that check the source system live.

This is a specialization of the metadata-and-permissions discipline covered in the ingestion pillar at /guides/rag-ingestion-and-chunking — ACLs are metadata that must survive parsing and chunking like any other field, and be filterable at retrieval. The broader access-control architecture for retrieval systems, including securing the retrieval tool inside agentic loops, is treated in the securing-RAG sections of /guides/agentic-rag-enterprise-guide; this guide's concern is narrower: whether the connector you are about to rely on captures ACLs at all, at what granularity, and how stale they are allowed to get.

5. Incremental sync and change detection

A knowledge index is a cache, and every cache needs an invalidation story. Bedrock's is explicit: "Syncing is incremental, so Amazon Bedrock only processes added, modified, or deleted documents since the last sync," with unchanged documents skipped, changed ones re-parsed, re-chunked, re-embedded, and re-indexed, and deletions removed from the vector store.^[8] It even implements a metadata-only optimization — when only a document's metadata file changes, existing embeddings are merged with the new metadata rather than regenerated, avoiding embedding-model calls.^[8] That detail matters at scale: re-embedding an entire SharePoint tenant because tags changed is real money.

The details differ per platform, and the differences are operationally significant. Google's connectors distinguish full syncs — which capture "the entire state of the third-party app or service," including deletions — from incremental syncs, which capture only "entity data that has been added or updated since the last sync."^[2] Deletions, in other words, ride the slower full-sync cadence; a document deleted for legal reasons can persist in the index until the next full sync completes. Azure's indexer detects deletions on the next run but has its own trap: "Renaming a SharePoint folder breaks incremental indexing. A renamed folder is treated as new content," and background Microsoft 365 processes that touch file metadata can trigger re-indexing with no real content change.^[3] None of these behaviors is hidden — they are all in the documentation — but each becomes an incident if discovered in production instead of in review.

6. Every source is messy in its own way

The connector layer is also where format diversity gets absorbed, and each source system distributes its knowledge differently. A useful tell for how a vendor thinks about this is what its filters and entities can address: Bedrock's Confluence connector applies inclusion/exclusion filters across five content types — spaces, pages, blogs, comments, and attachments^[4] — an implicit admission that a Confluence "document" is really a bundle of a page, its comment thread, and its attached files, each of which may carry the answer. If your connector ingests pages but drops attachments and comments, you have indexed the packaging and discarded the contents.

There is also a modality gap. Enterprise documents are full of tables, diagrams, and embedded images, and on Bedrock those survive ingestion only from S3 or custom sources — the Confluence and SharePoint connectors skip multimodal content entirely.^[6][4] If your engineering wiki's value is concentrated in architecture diagrams, a text-only connector will index everything except the point.

7. Build vs. buy at the connector layer

The default should be to buy: connector maintenance is a treadmill of API version changes, auth migrations (the ACS retirement forced every SharePoint integration to re-authenticate this year^[5]), rate-limit tuning, and permission-model edge cases, and none of it differentiates your product. But the managed offerings' own documentation defines the situations where custom ingestion stops being optional. Build — or buy a specialist connector product rather than a hyperscaler bundle — when any of the following holds:

• Your edition isn't covered. Bedrock's connectors support Confluence Cloud and SharePoint Online only^[4][5]; on-premises SharePoint Server or a self-hosted Data Center estate needs another path (Google's catalog does list Confluence and Jira Data Center as GA^[7]).
• The content that matters is multimodal. Diagrams, scanned documents, and embedded tables are skipped by the text-only third-party connectors on Bedrock; the workaround AWS itself provides is exporting to S3 or a custom data source, which is a custom pipeline by another name.^[6]
• Preview status conflicts with your risk posture. Azure says its SharePoint indexer is "not recommended for production workloads" and Microsoft's documented production alternatives are the Copilot Retrieval API knowledge source, Copilot Studio, or a self-built webhook-to-blob pipeline.^[3]
• The connector dictates your architecture. Bedrock's Confluence and SharePoint connectors currently require the OpenSearch Serverless vector store^[4][5]; if you have standardized on a different store, the managed connector is unavailable to you regardless of its feature list.
• Your security baseline is non-negotiable. Tenants with Conditional Access, private-endpoint requirements, or a refusal to relax MFA rule out specific managed paths on their documented limitations alone.^[3][5]
• Permission fidelity must be stronger than 'basic.' Where document-level ACL support is preview-grade or coarse, and the content is sensitive, query-time federation against the source system's own API — accepting the latency cost — beats replicating into an index whose trimming you cannot fully trust.^[3]

8. Honest objections

"The suite assistants make this whole layer moot." There is real force to this. Microsoft's answer to RAG over SharePoint is increasingly not "index SharePoint" but "query it live" through the Copilot Retrieval API, with no replicated index at all^[3]; Google's connector catalog is likewise attached to its own assistant surface. If your only use case is employees asking questions of their own documents inside the suite they already use, buying the suite assistant is simpler, keeps data in place, and inherits the native permission model. The counterargument is scope: the moment you build a custom application or agent — a support copilot grounded in Confluence plus your ticketing system, an underwriting assistant spanning SharePoint and a document management system — you are outside the suite assistant's boundary and back to needing a connector layer you control, spanning suites (most large enterprises run more than one) and feeding whatever orchestration and model stack you have chosen.

"Preview labels are just lawyer talk — the connectors work fine." Sometimes true; teams run preview services in production every day. But the preview caveats cataloged here are not boilerplate: they include concrete behavioral limits — 75-minute delegated tokens, basic-only ACL sync, folder renames breaking incremental indexing, "as-is" best-effort support, and no guarantee the feature ever reaches GA.^[3] The rational posture is not to refuse previews but to price them: assume the limitation list is accurate, assume the API may change under you, and do not put a preview connector on the critical path of a compliance-relevant retrieval flow.

"Fifty connectors beats six." Connector-count marketing rewards breadth, but an enterprise typically needs five to ten sources covered deeply, not fifty covered nominally. A connector that ingests Confluence page bodies but not attachments, or SharePoint libraries but not lists, checks the logo box while missing the knowledge. Evaluate the handful of connectors you will actually run — against your editions, your permission model, and your deletion requirements — and weight those findings over any catalog length.

9. The read

Treat the connector layer as a first-class architecture decision with three possible answers per source system, chosen deliberately: replicate through a managed connector where coverage, permissions, and sync semantics documented today are adequate; federate at query time through source-native retrieval APIs where permission fidelity or data-residency posture forbids replication; and build custom ingestion only where the documented limitations of both leave no alternative — and the source is valuable enough to fund the treadmill. Most enterprises will land on a mix, and the mix will differ by source: a managed connector for the general document estate, live federation for the sensitive HR and legal spaces, custom pipelines for the diagram-heavy wiki and the conversational archives. What should not survive this review is the assumption, inherited from the demo, that the corpus is a folder of PDFs waiting in object storage.

10. How to apply this