RAG on SharePoint with n8n: query your Microsoft 365 documents

Years of meeting notes, procedures, contracts and slide decks sit idle in SharePoint and OneDrive. Native search finds a file when you already know its name; for a question like "what's our travel expense reimbursement policy?", nobody knows which site, which library, which version to look in. That's exactly the problem RAG (retrieval-augmented generation) solves, and its principle was laid out in the founding paper by Patrick Lewis et al. presented at NeurIPS 2020 ("Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", see on Google Scholar): grounding a language model's generation in retrieved documents produces answers that are more factual and more specific than the model alone — and makes it possible to cite the source. Here's how to build that assistant on your Microsoft 365 tenant with n8n.

Architecture: two workflows

As with a Google Drive RAG, the system splits into two independent workflows:

1. Indexing: walk the SharePoint libraries via Microsoft Graph, download the files, extract the text, chunk it, vectorize it, insert it into a vector store with its metadata.
2. Querying: a chatbot that searches that store and answers with a link to the source document.

INDEXING (Schedule Trigger)
Graph: /sites/{site-id}/drives
  → /drives/{drive-id}/root/children (recursive walk)
  → /drives/{drive-id}/items/{id}/content (download)
  → Extract from File (PDF, DOCX)
  → Chunking → Embeddings → Vector Store (Supabase pgvector / Qdrant)

QUERYING
Chat Trigger → AI Agent ←→ Vector Store (retrieval tool)
  → answer + SharePoint URL of the cited document

The separation matters: indexing runs overnight on a schedule, querying answers around the clock; each evolves without breaking the other.

Accessing SharePoint: app registration and Microsoft Graph

Everything goes through the Microsoft Graph API, called from n8n with the HTTP Request node and a Microsoft OAuth2 credential. The groundwork happens in Azure:

1. In Entra ID (formerly Azure AD), create an app registration and note the client_id and tenant_id, then generate a client_secret.
2. Under API permissions, add Sites.Read.All or Files.Read.All as application permissions (not delegated), then have an administrator grant admin consent.
3. The client credentials flow is the right choice here: your indexing workflow is a service running overnight, not a user in front of a screen. n8n obtains a token in its own name, without depending on a human account's session that expires or leaves the company. It's the same principle as automating Outlook and Microsoft 365 with n8n, where the Azure setup is covered step by step.

The token comes from https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token with the scope https://graph.microsoft.com/.default; n8n's OAuth2 API credential in client credentials mode handles renewal automatically.

The Graph endpoints of the indexing pipeline

Three calls are enough to walk a document library. First, identify the site and its drives (each SharePoint document library is a "drive" in Graph terms — OneDrive uses the same API):

GET https://graph.microsoft.com/v1.0/sites/{hostname}:/sites/{site-name}
→ returns the site-id

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives
→ lists the libraries (each one's drive-id)

Then, list a drive's files:

GET https://graph.microsoft.com/v1.0/drives/{drive-id}/root/children
→ files and folders at the root; for a subfolder:
GET https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{folder-id}/children

Each returned item carries name, lastModifiedDateTime, createdBy, parentReference.path and above all webUrl — the document's SharePoint URL, worth guarding carefully for citations. Folders have a folder property: a small recursive sub-workflow (the HTTP Request node in a loop over folder-type items) walks the whole tree. Mind the pagination: Graph returns pages through @odata.nextLink.

Finally, download the binary content:

GET https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{item-id}/content
→ the file itself (a 302 followed automatically by HTTP Request, set to "File" as the response format)

Filter on the extension upstream: PDF, DOCX, PPTX and TXT are worth indexing; images, videos and archives only add noise.

Extraction, chunking, insertion

The downloaded binary goes into Extract from File: the PDF operation for PDFs, and DOCX text extracts just as directly. Scanned PDFs without a text layer need OCR upstream — Graph won't do that work for you.

The extracted text then follows the classic RAG pipeline: splitting into 500-to-1,000-token chunks with overlap (the full rules are in our guide to document chunking for RAG), vectorization with the model chosen per our embedding model comparison, then insertion through a Vector Store node — Supabase pgvector if you'd rather stay in SQL (Supabase setup here), Qdrant as a dedicated engine.

Each chunk's metadata makes the difference between an index and a good index. Store at minimum:

• the Graph item_id and drive_id (the reindexing key);
• site and path (the parentReference.path, to filter by library);
• author (createdBy.user.displayName) and last_modified;
• web_url — the field that turns every chatbot answer into a sourced answer, with a clickable link to the document in SharePoint.

Incremental synchronization

Reindexing an entire tenant every night doesn't hold up beyond a few hundred files. Two mechanisms, from simplest to most robust:

• lastModifiedDateTime filter: a nightly Schedule Trigger lists the files and only processes those modified since the last run (date stored in a workflow variable or a table). Simple, but it misses deletions.
• Graph delta query: the GET /drives/{drive-id}/root/delta endpoint returns every change — creations, modifications and deletions — since the last call, materialized as an @odata.deltaLink token to keep between runs. It's the mechanism designed for exactly this case.

In both cases, the golden rule: for every modified file, first delete all vectors carrying its item_id, then insert the new chunks — otherwise versions pile up and the chatbot cites outdated procedures. The full index lifecycle (updates, deletions, reconciliation) is covered in detail in our guide to keeping a RAG index up to date.

The query workflow

The downstream half is standard RAG: a Chat Trigger opens the conversation interface, an AI Agent receives the question, and the Vector Store node attached as a tool of the agent performs the retrieval. In the agent's system prompt, enforce two rules: answer only from the retrieved passages, and end every answer with the source(s) — the web_url stored as metadata, formatted as a Markdown link to the SharePoint document. The user gets the answer and a one-click way to verify it, which changes everything for internal adoption.

If relevance plateaus on exact terms — product references, project names, the internal acronyms SharePoint is full of — hybrid search (vectors + keywords) is the first lever to pull.

Warning: the index ignores SharePoint permissions

The governance point that must be settled before going to production: your app registration reads everything its permissions cover, and the vector index keeps no trace of SharePoint ACLs. A confidential HR document, once indexed, becomes readable by every chatbot user, including those with no access to the original site.

The safeguard: index by scope. One index (or collection) per user population — one for documents open to the whole company, one for leadership, one per team if needed — and a chatbot that only queries the indexes its audience is entitled to. Failing that, store the source site as metadata and filter at query time per user. Without this guardrail, your documentation assistant is a remarkably efficient internal data leak.

The same blueprint applies to your other sources, by the way: this article's pipeline transposes almost as-is to Notion or Google Drive — only the file access layer changes, the RAG core stays identical.