Connect each source once — Gmail, Slack, Google Drive, Notion — through a layer that both assistants query as an external tool, and have it return the source record alongside every fact. The assistant searches your data at question time rather than being trained on it, and you can open the message or file behind any claim it makes.
What "with citations" has to mean
An assistant that answers from your company data without showing where the answer came from is worse than one that cannot see your data at all, because the confident wrong answer is indistinguishable from the right one.
A citation here is narrow and specific: the retrieval step returns the source record with each fact — which message, which file, which page — and the assistant renders it as a link you can open. That gives you two things a bare answer cannot. You can check the original wording, and you can see the date, which is usually what separates a fact that is still true from one that expired two quarters ago.
Be clear about what a citation does not do. It does not prove the answer is correct — an assistant can cite a real document and still summarise it badly. It is a check you can run, not a guarantee you can skip.
How permission-aware retrieval works
Four steps, and the permission question is settled in the first one, not the last.
- Connect a source. You authorize the connection through the provider's own OAuth flow. You are consenting as yourself, so the connection can only ever reach what your account can reach. There is no password to hand over and no shared service account.
- Sync into an isolated workspace. Content is pulled into a workspace scoped to you or your team, encrypted at rest, and indexed for search.
- Search at question time. When an assistant asks a question, the layer searches the workspace and returns matching passages with the record each came from.
- Answer with sources. The assistant answers from those passages and renders the links.
Two properties are worth insisting on. Retrieval is at question time, so nothing is baked into a model and correcting a record corrects future answers. And the workspace boundary is enforced at the database layer — in GreatArrow.ai every workspace-scoped table is isolated there, so another tenant's rows are refused by the database rather than filtered by application code that could have a bug.
Which sources you can connect
GreatArrow.ai supports 40 connectable source types. The four this guide is about:
| Source | Auth | What becomes searchable | Notes |
|---|---|---|---|
| Gmail | Google OAuth | Messages and threads in your mailbox | Scoped to your own account; see Connect Gmail to Claude |
| Slack | Slack OAuth | Messages and threads | Limited to the channels you allow at authorization; see Connect Slack to Your AI Assistant |
| Google Drive | Google OAuth | Documents and their contents | Includes Docs, Sheets and Slides as separate source types |
| Notion | Notion OAuth | Pages and databases | Notion's own consent screen controls which pages are shared |
The rest of the catalogue covers mail and calendar (Outlook, Google Calendar), chat (Teams, Discord), storage (OneDrive, SharePoint, Dropbox), work tracking (Jira, Linear, Asana, Confluence), code (GitHub, GitLab), meetings (Zoom, Granola, Fireflies), design (Figma, Canva), CRM and finance (HubSpot, Salesforce, Stripe, QuickBooks), and platform tools (Vercel, Supabase, Sentry). The live list is in the product at /integrations.
A source you have not connected is not searchable. That is the intended default: connecting one source is a complete setup, and most people start with whichever one they waste the most time searching by hand.
Security, in specifics
Vague assurances are not useful when you are deciding whether to connect a mailbox. The specifics for GreatArrow.ai:
- Encryption at rest. Stored content and the credentials for connected tools are encrypted with AES-256-GCM at the application layer.
- Tenant isolation. Every workspace-scoped table is isolated at the database layer.
- Access keys. Each connected client's key is stored as a one-way fingerprint and shown to you exactly once. Any of them can be revoked from your account, effective immediately.
- Your own key. Enterprise workspaces can supply their own encryption key on top of the above.
- Training. Your content is processed to answer your requests. It is not used to train third-party models, and Great Arrow does not use it for its own model training without separately-given consent.
The full statement is on the security page. Note what is not claimed there: no compliance certification is asserted on that page, so if a certification is a procurement requirement for you, ask before you assume — do not read this guide as a certification claim.
A concrete example
A client emails: "We've decided to go annual — monthly billing won't clear our procurement."
You ask Claude what the billing terms for that account are. The layer searches your connected Gmail, finds that message, and returns it as a passage with a link to the thread. Claude answers "annual, invoiced" and shows the email it read.
Two months later someone else asks the same question in ChatGPT. Same workspace, same message, same answer — and the same link, so they can see it came from the client rather than from an assumption someone made.
If the client later reverses the decision, the new email is the newer record. You can see both, dated, which is the part a context file you maintain by hand cannot do.
How this compares to the alternatives
Native ChatGPT and Claude connectors are the shortest path if you use one assistant. They are built by the vendor, well integrated, and require no third party. Their limit is exactly their strength: the connection is configured inside one vendor's product, so using a second assistant means configuring the same sources again there, with separate permissions and separate behaviour.
Enterprise search (Glean and similar) indexes a whole organisation's tools and is built around company-wide permission mirroring. If you are deploying to hundreds of people and need existing document ACLs reflected exactly, that is the category to look at — it does a job a lightweight layer does not attempt. It also carries the cost and rollout that implies.
A shared context layer sits between them. One connection per source, read by every client you use, sized for a person or a team rather than an enterprise directory.
None of these dominates. Use one assistant and only need files? Use its native connector. Rolling out to a large organisation with strict ACL mirroring? Look at enterprise search. Using several assistants and want them to agree? That is the case a shared layer is actually for. The comparison page sets out the trade-offs by capability.
Who this is for, and who it is not for
It is for you if you already answer questions by searching your own email and documents by hand, and you use more than one assistant.
It is not for you if you cannot connect the source at all — some regulated environments will not permit third-party OAuth to a mailbox, and no product feature changes that. It is also unnecessary if your data is already in one place with good search and you only use one assistant against it.
Where to go next
Share Context Across Claude, ChatGPT and Cursor covers the client side of the same setup. Stop Re-Explaining Your Company to Every AI Tool starts from a manual template if you want to try the free version of this first.
Per-source walkthroughs: Gmail, Slack, GitHub, and ChatGPT as a client. Setup starts at /install; the capability list is on features and plans are on pricing.