AI CTRL Standard Data Connectors for RAG

Prev Next

Standard Data Connectors for RAG

Supported platforms

Connector Provider
SharePoint (Cloud / Online) Microsoft
OneDrive (Enterprise) Microsoft
Google Drive Google
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:

  1. 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.
  2. 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.


Supported file types

Whether a file gets indexed, and whether it shows up in semantic search once it is, depends on its extension and which connector ingested it. A file ends up in one of three states: extracted and searchable, dropped with no record at all, or recorded but not searchable.

Dropped before indexing (SharePoint only)

SharePoint removes these files at listing time. Nothing is written for them, no document, no metadata, no placeholder.

Group Extensions Count
OneNote .one .onetoc2 2
Windows binaries and scripts .dll .exe .msi .com .bat .cmd .ps1 7
Archives .zip .rar .7z .gz .tar 5
Fonts .ttf .otf .woff .woff2 4
Shortcuts and config .lnk .url .ini 3
Backups and temp .bak .tmp .download 3
Legacy desktop databases .dbf .wk4 .wk1 3
CAD and engineering .ref .dwg .dxf .ipt .iam .dae .dad .cgm .catpart .catproduct .sldprt .sldasm .step .stp .iges .igs .prt .x_t .x_b 19

Files with no extension, and files whose name starts with __, are dropped the same way.

Other connectors apply their own naming rules for what gets dropped outright:

Connector Dropped with no document
SharePoint No extension, or the name starts with __
Box Name starts with __
Dropbox Name starts with . or ~

Extracted and searchable

This is the default allowlist and applies to every connector. A file with no usable extension is still extracted if its content type is text, image, PDF, Word, or PowerPoint.

Group Extensions Count
Documents .pdf .doc .docx .odt .rtf .msg 6
Spreadsheets .csv .tsv .xls .xlsx .xlsb .xlsm 6
Presentations .ppt .pptx .potx 3
Text, markup, and code .txt .md .markdown .rst .html .aspx .json .xml .svg .py .rb .sh .paper 13
Diagrams .vsd .vsdx .vsdm 3
Images .png .jpg .jpeg .jpe .jfif .tif .tiff .jp2 .j2k .jpf .jpx .jpm .gif .webp .bmp .dib .pnm .pbm .pgm .ppm 20

Some connectors also extract native content that isn't a file at all:

Connector Extracted as text
Notion Pages, databases, comments
Confluence Pages and blog posts. Attachments follow the file allowlist above.
SharePoint Modern site pages (HTML)
ServiceNow Knowledge articles, incidents, changes, problems

Recorded but not searchable

An unsupported extension doesn't always disappear without a trace, behavior differs by connector:

  • SharePoint drops it entirely, as above: no document written.
  • OneDrive, Box, Dropbox, and Google Drive write a metadata-only document instead, for the same extensions SharePoint drops plus other unsupported types (.onepkg .mp4 .mov .wmv .avi .mkv .mpg .mp3 .wav .wma .aac .eml .pst .mdb .accdb .dat .bin .log .heic .ico). That document exists, but doesn't come back in a semantic search.

Files over the 100 MB download cap are handled the same way as unsupported extensions, even when the file type is on the allowlist. A 200 MB PDF produces a metadata record, not a searchable one.

Extending the allowlist

The allowlists above are defaults and can be extended for a specific deployment. If a file type you need indexed isn't listed, request it through your Expedient Account Manager rather than assuming it'll pick up automatically once added to the source.


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.