As of June 26, 2026, the hard part of AI office search is not turning on one more connector. The hard part is deciding which internal source should be trusted for each kind of question.

OpenAI's company knowledge documentation describes ChatGPT retrieving relevant information from connected work sources for eligible business workspaces. Its broader connectors documentation explains that apps and connectors can bring outside services into ChatGPT, while OpenAI's admin-control guidance points admins toward managing app availability, permissions and security controls.

Those docs are useful. They do not answer the local office question for your team: which source should ChatGPT search first, and what should it ignore?

Start with the questions people actually ask

Do not make the first source map from your tool list. Make it from the questions people want answered.

Write down ten real office-search questions. Keep them boring:

  • What is the current refund policy?
  • Which customer renewal is at risk this week?
  • Where did we decide the launch date?
  • What changed in the latest pricing deck?
  • Who owns the handoff after a support escalation?
  • Which internal checklist applies before we send this document?

Then mark the expected source beside each question. A policy question might belong in a controlled document. A launch decision might belong in a project channel plus a final project brief. A customer-status question might belong in the CRM, not in a shared folder full of exported notes.

If the team cannot name the expected source, ChatGPT cannot fix that by searching more places. It may find an answer, but the answer will inherit the same source confusion the team already has.

Separate final records from working memory

Every source in an office-search map should have a job.

Final records are where the team expects the current answer to live: policies, pricing sheets, approved process docs, customer records, contracts, decision logs and maintained knowledge-base pages.

Working memory is where the team talks before the answer becomes final: chat threads, meeting notes, drafts, comments, planning boards and quick exports.

Both can be useful. They should not be treated the same.

Use final records for questions where the answer will travel outside the person asking. Use working memory to find context, owners, blockers and unresolved decisions. If ChatGPT cites a chat thread for a current policy answer, the source map should make that a warning, not a success.

The practical rule is simple: a connected source is allowed to help answer only the questions it was meant to own.

Score each source before connecting it

Give every candidate source a quick score before it becomes part of the pilot:

  • Owner: who is responsible for keeping this source current?
  • Freshness: how often does it change, and how will stale items be removed?
  • Permissions: are user permissions already clean enough to mirror in ChatGPT?
  • Source quality: does the source contain final answers, drafts, duplicates or side comments?
  • Citation value: can a user inspect the specific document, message or record behind the answer?
  • Risk: what happens if ChatGPT pulls from this source at the wrong time?

This score is not paperwork for its own sake. It tells you whether a source belongs in the first pilot, a later pilot or no pilot at all.

A clean policy folder with a clear owner may be ready. A shared drive with old exports, duplicate decks and mixed customer files is not. A CRM with controlled records may be better for customer-status questions than a folder of meeting summaries. A chat channel may be useful for finding who discussed a decision, but weak for confirming the final decision.

Map source types to answer jobs

The source map should be concrete enough that users know what kind of answer to expect.

Use a simple table before you configure anything:

| Question type | Best first source | Use with caution | | --- | --- | --- | | Current policy | Approved policy docs | Chat threads, old PDFs, copied notes | | Project status | Project brief or tracker | Meeting transcripts without owners | | Customer status | CRM or ticket system | Personal notes, exported spreadsheets | | Recent discussion | Scoped chat or channel history | Company-wide chat search | | Document check | Known file upload or approved folder | Random files from a broad drive | | Process ownership | Maintained process doc | Informal messages with stale names |

This is where connector choice becomes easier. If the job is current policy, start with the source of truth. If the job is "what did people say last week?", a scoped chat source may help. If the job is "check this one deck before the meeting," a manual file upload may be enough.

Keep Drive and chat pilots narrow

OpenAI's Google Drive sync documentation and Microsoft Teams sync documentation are good examples of why source mapping comes first. Drives and chats contain many different kinds of knowledge in one place.

A shared drive may contain final policies, rough drafts, exports, duplicate slide decks, personal notes and files with inherited permissions. A Teams scope may contain useful project decisions, but also side comments, unresolved options and references to files or recordings that are not actually part of the searched message content.

Do not pilot broad drive or chat search because the connector exists. Pilot one source area because it answers one named question better than the alternatives.

For a first Drive-style pilot, pick one folder or shared drive area with a visible owner and a cleanup rule. For a first chat-style pilot, pick one project or operations scope where the team knows what kind of discussion should be retrieved. Then test known-answer prompts before asking users to rely on it.

Decide what ChatGPT should not search

A source map is also an exclusion map.

List the sources that should stay out of the first pilot:

  • folders with legal, HR or finance material mixed into ordinary docs;
  • exported customer files with unclear retention rules;
  • duplicate policy docs with no owner;
  • private chats that are not meant to be a company record;
  • stale project folders from completed work;
  • systems where write actions or broad app permissions would complicate a search-only pilot.

This matters because office search often fails quietly. A bad answer may look polished. A source map gives reviewers a reason to ask, "Why did it use that source?"

Test the map before expanding access

Before the pilot reaches more users, run a small test set:

  • five questions that should be answered from the connected source;
  • three questions that should say the source does not answer;
  • two questions where permissions should change the result;
  • two questions where an old draft would be tempting but wrong;
  • one question where the answer should point to a human owner instead of pretending certainty.

Ask ChatGPT to show source links, dates, uncertainty and any missing context. Then check the source yourself. If the answer is correct but the source is wrong, the pilot is not ready. If the answer is vague because the source is messy, fix the source before widening the connector.

The small-team rule

Build the source map before the connector map.

For each office-search question, name the expected source, owner, freshness rule, permission boundary and verification habit. Only then decide whether the first step is company knowledge, a Drive scope, a Teams scope, a custom connector or a one-off file upload.

That order keeps AI office search from becoming a fluent layer over messy internal data. The goal is not for ChatGPT to search everything. The goal is for it to search the few sources that actually deserve to answer the question.