Connect RAG data sources: SharePoint, DMS, ERP, CRM & databases

For enterprise RAG, the initial document import is rarely the hard part. What matters is whether document identity, permissions, freshness, versions and deletions remain correct throughout the entire lifecycle.

A vector index may be populated flawlessly and still produce unreliable or impermissible answers: an obsolete policy remains beside the current version, a moved file appears as a second document, or a revoked permission reaches retrieval days too late.

Embeddings do not solve lifecycle problems. Dependable RAG ingestion starts with identity, permissions, lifecycle and provenance — only then with chunking and indexing.

For the broader retrieval and evaluation architecture, see Build a RAG system the right way.

Why “connect a connector” understates the task

A connector initially proves only that it can read data. For an existing business application, it needs to do more: identify which business document changed, which version is valid and who may currently see it. It must also make clear why a piece of content is in the index — and remove it when the source deletes it or becomes unavailable.

This is not a one-off import. It is a data contract between source system, ingestion and retrieval. Filenames and URLs are often only attributes in that contract. Both can change without creating a new business document.

A document lifecycle, not one-time ingestion

A production pipeline handles at least these states:

• Create: Add a new object with provenance, canonical identity, version and ACLs.
• Update: Content or relevant metadata changes; replace the affected chunks and index entries.
• Move or rename: Path and title change while business identity remains stable.
• Permission change: Content remains unchanged, but the retrievable audience changes immediately.
• Delete: Remove every related document, version and chunk entry from retrieval.
• Restore: Re-introduce a restored object in a controlled way as the current lifecycle state.
• Source unavailable or stale: A source that has missed changes is a visible operational state, not a silent assumption of freshness.

Delete propagation is a production-readiness criterion. If deleted documents or revoked rights remain effective in retrieval, the pipeline is not production-ready regardless of embedding quality.

Identity: from source file to chunk

A filename or URL is often not stable identity. The same SharePoint file may be renamed and moved several times. A DMS may add a file version to the same business record. The same information may also appear in a product database or CRM.

A dependable pipeline separates several layers:

The canonical document ID is not cosmetic metadata. It prevents a move from becoming a new document, enables deduplication and keeps the relationship between source, version and chunk explainable. Where multiple systems hold the same information, the organisation needs an explicit source of truth; semantic similarity cannot decide that.

ACLs belong in the ingestion data model

Permissions are not a later filter applied after an answer has been generated. They belong in the ingestion data model and must remain intact through retrieval.

This includes source ACLs and their mapping to identities in the business application: users, groups, roles and, where needed, tenants. Retrieval may return only candidates allowed in the current user context. This security trimming must still work when group membership or document rights change without a single character changing in the document.

A service account with broad read access can simplify import, but it does not replace access control in the target system. For ACL mapping, revocation and retrieval-time filtering, see RAG permissions & security trimming.

A concrete enterprise scenario: service knowledge from multiple sources

An existing service application should give employees source-backed answers. Its knowledge lives in SharePoint, a DMS and a product database or CRM:

• SharePoint contains work instructions that a team moves and updates.
• The DMS holds approved documents with multiple versions and status.
• The product database or CRM provides approved product and account context.
• Different user groups may access different areas.

A SharePoint file is renamed, later moved to another library and then updated. Its source-native ID keeps it together as one object; the new version replaces its previous chunks. In parallel, an approved DMS version of the same policy exists. The application must use explicit canonical identity and a defined source of truth to decide which information is authoritative — not index both blindly.

If only a permission changes, content stays unchanged but ACLs still need updating. If the file is deleted or access is revoked, none of its chunks may remain retrievable. If the source has been unavailable since the last successful run, operations and the application need a visible stale state rather than an apparently current answer.

Architecture view: sequence is a security and quality decision

RAG ingestion: lifecycle before embeddings

1. 01

   Source Systems

   SharePoint, DMS and product database or CRM as business sources

2. 02

   Connector & Change Detection

   Recognise create, update, move, permission change, delete, restore and stale status

3. 03

   Identity & ACL Mapping

   Source-native IDs, canonical identity, versions, provenance plus user, group and tenant rights

4. 04

   Parsing & Normalization

   Preserve text, structure, tables, status and business metadata deliberately

5. 05

   Chunking & Indexing

   Send only current, unambiguously attributable content to search and vector indexes

6. 06

   Permission-aware Retrieval

   Apply the current user context, return permitted evidence and link back to the source

The implication of this sequence is simple: a change at the front of the chain must propagate in a controlled way to every affected index entry. An index is not a second source system. It is a derived, explainable view of authoritative data.

Parsing and normalization before chunking

A file is not automatically useful retrieval content. PDFs, Office files, HTML and scans can lose tables, headings, page references or approval status during parsing. Careful chunking cannot repair structure that has already been lost.

Normalization therefore places content and metadata in a consistent document model: title, source, status, validity, version, ACLs and provenance remain connected to extracted content. Only then can the pipeline decide which semantic units should become chunks and which current version may enter the index. For this stage in more detail, see RAG chunking strategies for better answers.

Managed connector or custom pipeline: decide by semantics

A managed connector is attractive when the source is standard and it transparently preserves the semantics that matter: ACLs are captured correctly, lifecycle events are reliably detected, update and deletion behaviour is documented, and failures or stale states are observable. In that case it reduces implementation and operating effort without concealing the critical data contract.

A custom pipeline is appropriate for proprietary sources, complex business logic, specialist normalization or unusual permission models. It is also justified when several sources must be joined to a canonical identity or when the existing application needs controlled provenance. Custom does not mean rebuilding search or embeddings; often a narrow integration adapter at the business boundary is sufficient.

For the wider decision about ownership and replaceable RAG layers, see Enterprise RAG: Build, Buy or Hybrid?.

Make the architecture decision before index optimisation

A dependable RAG ingestion layer should not start with embeddings. First make identity, permissions, lifecycle and provenance stable. Only then is it worth optimising chunking, hybrid search or indexing against real questions.

If delete propagation and permission updates are not reliable, the pipeline is not production-ready — regardless of embedding quality. For the SharePoint and DMS-specific details, see Connect SharePoint to RAG and Connect a Document Management System to RAG.

If sources, access rules and lifecycle behaviour are already concrete for your application, I can help with RAG implementation and AI integration. If the source of truth, integration boundaries and operating model still need to be clarified, AI architecture consulting is the better starting point.

Technical guidance on privacy and compliance does not constitute legal advice.