Connecting Confluence, Drive, and email into one search

Your organization's knowledge is rarely missing — it's just scattered across systems that don't talk to each other, and unifying search across them is a more solvable problem than teams expect.

Why fragmented knowledge feels worse than it is

The frustrating part of scattered knowledge isn't that any single system is bad — Confluence, Google Drive, and email each work fine on their own. It's that finding an answer requires knowing (or guessing) which system it lives in before you can even start searching, and that guess is often wrong. A policy document might be in Confluence, or it might be an email attachment from eight months ago, or a Google Doc someone shared once and never properly filed. Unified search removes the "which system" guess entirely.

How unified search actually gets built technically

We build a connector layer that ingests content from each source system via their respective APIs — Confluence's REST API, Google Drive's API, and email via IMAP or a Gmail/Outlook API integration — extracting text content, metadata (author, date, source location), and access permissions. This content gets chunked and embedded into a unified vector index, so a single search query retrieves relevant results across all connected sources ranked by semantic relevance, not by which system happens to contain a keyword match.

The permissions piece is critical and often underestimated: the unified search index needs to respect each source system's existing access controls, so a search doesn't surface a document to someone who wouldn't have had access to it in the original system. We propagate permission metadata at ingestion time and filter search results against the querying user's actual access rights, not just index everything openly.

Incremental sync, not one-time import

A one-time content import solves the problem for a moment and then starts degrading immediately as new documents get created and old ones get updated. We build incremental sync — typically polling each source's API on a defined interval, or using webhooks where the source system supports them — so the unified index stays current without requiring manual re-imports.

A concrete example

A professional services firm had institutional knowledge spread across Confluence (technical documentation), Google Drive (client deliverables and templates), and years of email threads (informal but often critical decisions and client communications). Staff reported regularly recreating documents that already existed somewhere, purely because they couldn't locate the original. We built a unified search layer connecting all three sources with permission-aware indexing and hourly incremental sync. In a post-launch survey, staff reported a significant reduction in "I couldn't find it so I recreated it" incidents, and search query logs showed the tool being used an average of several times a day per active user within the first month — indicating real adoption, not a one-time curiosity check.

Where teams get stuck

Email is consistently the hardest source to integrate well, both technically (inbox structures are messier and less standardized than a wiki) and in terms of what should actually be indexed — not every email is institutional knowledge worth surfacing in search. We typically scope email integration to shared/team inboxes and explicitly-flagged important threads rather than attempting to index every individual's entire personal inbox, which introduces both noise and privacy concerns.

How Ndakum approaches it

Unified search across fragmented systems is a core capability we build in our AI Knowledge Assistant work — connecting to your existing tools rather than asking you to migrate everything into one new system.