Standard Data Connectors for RAG
Supported platforms
| Connector | Provider |
|---|---|
| SharePoint (Cloud / Online) | Microsoft |
| OneDrive (Enterprise) | Microsoft |
| Google Drive | |
| Dropbox | Dropbox, Inc. |
| Box | Box, Inc. |
| Confluence (Cloud) | Atlassian |
| ServiceNow | ServiceNow, Inc. |
| Notion | Notion Labs, Inc. |
| Amazon S3 | Amazon Web Services |
If your content lives somewhere else, see Custom Data Connectors below.
What counts as one connector
A connector represents one platform or content source. Each connected source has its own ingestion pipeline and is configured independently.
This distinction applies even when multiple sources belong to the same vendor. For example, SharePoint Online and OneDrive are separate connectors, not a single Microsoft connector. They use separate app registrations and ingestion pipelines, and each requires its own credentials and access configuration.
A separate connector is not required for differences in content organization after ingestion. Maintaining separate search scopes or exposing content through multiple searchable tools in the frontend are configuration options, not separate connections.
What a connector does
A data connector indexes the documents in a system you already use, so AI CTRL can search them by meaning rather than by keyword and answer questions from them — with citations back to the original file.
That makes connectors a good fit for text: policies, procedures, knowledge articles, contracts, written guidance. Someone can ask about "escalating an angry customer" and find the right document even if it never uses that phrase.
| Good fit | Not a fit |
|---|---|
| Natural-language questions against documents | Real-time transactional processing |
| Policy, procedure, and knowledge lookup | Replacing SQL or reporting tools |
| Summarizing across several documents at once | Dashboards and trend visualization |
| Answers with sources you can check | Live operational reporting |
| Follow-up questions on the same content |
This is not a BI tool. For scheduled reporting and dashboards, a purpose-built BI platform is still the right answer.
Spreadsheets in a connected source
Spreadsheets are handled differently from documents, and understanding why is worth a minute.
The problem with treating a spreadsheet as text. Retrieval works by splitting a file into pieces and matching your question against them. Do that to a table and you get a few rows at a time, cut off from the headers and from the rest of the data. Ask "how did we do this year?" and you might get partial figures from three scattered years — and the model will usually answer anyway, confidently, from an incomplete picture. That's worse than no answer.
What AI CTRL does instead. Spreadsheets in a connected source are processed in two parts:
- A description of the table — what it contains and what it's for — is generated from its headers, data types, and a sample of its contents. That description is what your question is matched against, so the right spreadsheet gets found.
- The table itself stays queryable. Once the right file is identified, AI CTRL runs a direct query against the full table rather than reading fragments of it.
Multi-tab workbooks are handled tab by tab, so each sheet is treated as its own table.
Why it matters. Calculations are performed by querying the data, not by the model estimating from whatever text it happened to retrieve. Sums, averages, sorting, and filtering come back computed against the complete table.
Even so, treat this as a way to answer questions about your data — not as a replacement for reporting. A BI platform answers the questions you already knew to ask, on a schedule. This answers the question you have right now, about a file already in your document store.
What we need from you
Expedient configures and maintains the connector. Your organization creates and maintains the access it uses.
- A dedicated application or service account in your platform — an OAuth app registration in Azure for SharePoint Online, a service account in Google Workspace, an IAM role policy in AWS for S3
- Read-level permissions to the repositories or sites you want indexed
- The credentials themselves, sent by a secure method — client ID, tenant ID, certificate or key pair, API token
- Ongoing maintenance — renewing certificates, rotating secrets before they expire, and telling us when access changes
Credentials that lapse stop the sync. The connector doesn't fail loudly; it stops collecting, and search results quietly go stale. Expiring secrets are worth tracking on your side.
Timeline
For a standard integration of 50,000 documents or fewer, expect 5 business days from the point valid credentials are confirmed — not from the date of the request. That covers configuration and authentication, the first ingest, and search validation.
Larger volumes, unusual file types, and complex permission scopes all extend it. The most common cause of delay by a wide margin is waiting on client-side access.
Once the connector goes live it runs a full content sync, collecting and indexing everything available to it. Depending on volume that takes hours to days. After that it moves to an incremental sync once daily, picking up only what's changed — new files, edits, and deletions — rather than reprocessing the whole repository.
Keeping results accurate
RAG is only as good as the documents behind it. A connected repository full of stale and duplicated files will produce stale and contradictory answers, and it will do so confidently.
| Problem in the source | What it does to answers |
|---|---|
| Outdated or superseded documents | Obsolete information gets presented as current |
| Duplicates and near-duplicates | Conflicting answers, and less reason to trust any of them |
| Vague or generic file names | Harder to rank the right document first |
| Large volumes of irrelevant content | More noise retrieved, less precision |
| Inconsistent terminology | Queries don't match the language of the documents |
| Missing documents | Gaps show up as hedged or incomplete answers |
The fix is unglamorous and it works: point the connector at content that's already curated, and review it periodically to remove what's gone stale.
Custom Data Connectors
For content that isn't on the supported list, Expedient builds custom connectors against most sources with an accessible API — proprietary internal platforms, industry-specific applications, legacy document management systems.
The principle is the same as a standard connector: collect text-heavy content, index it, make it searchable by meaning. The difference is scope. Custom connectors require design, development, and ongoing maintenance, so additional fees may apply for both the build and continued support.
Every custom connector starts with a Statement of Work defining the source, access requirements, document volume, and what you expect to get out of it.
To start, contact your Expedient Account Manager. They'll assess feasibility and coordinate the SOW.