Introduction
Sana connectors play a crucial role in extending the power of our AI agents. They enable Sana to securely read from and write to a wide range of external systems. This allows Sana to:
Use live business data to provide precise, contextually relevant responses
Take action on your behalf by updating records directly in those systems
Types of connectors
Connectors in Sana follow two key characteristics:
Personal: Each connector is tied to your own account in the third‑party application. Sana mirrors your access which means that you can only access the data that you are allowed to see and act on in that system and nothing you connect is automatically shared with your colleagues.
Real-time: When Sana uses a connector, it calls the underlying APIs of the third‑party application in real time. This means Sana always works with the latest available data rather than a stale data.
FAQ
Q: Can my colleagues see the data in the connectors that I connect?
A: No. Connectors are personal and mirror your own permissions in the third‑party application. Sana only accesses what you are allowed to access, and this is not shared with others by default.
Q: How often is the data from the applications updated?
A: Data is fetched in real time when you ask Sana a question or trigger an action. There is no separate sync schedule; Sana always retrieves the latest data directly from the source system.
Q: Do you ingest and index the data in these applications?
A: No, Sana does not pre‑ingest or index your data. Instead, Sana makes API calls in real time to fetch just the relevant data needed to answer your question or complete an action. This means we do not maintain a full copy of your application data for these use cases.
Q: When connecting to some connectors it says that Sana uses Pipedream. What is that?
A: Pipedream is an integration platform (part of Workday) that makes it easier and more secure to connect to many third‑party applications via their APIs. Sana uses Pipedream’s technology as an infrastructure layer for some connectors, instead of rebuilding all of those integrations in‑house. This lets us support more systems, more quickly, while relying on a proven, enterprise‑grade integration service.
Q: Can an admin connect an integration on behalf of users, or push it to a group?
A: No. Connector instances are personal by design: each user completes their own authorization flow for each connector they want to use. Admins control which connectors are available in the workspace, not which accounts individual users connect. There is no way to push a connected instance to a user or a group.
Q: Can I connect two accounts for the same application, for example a personal and a work Gmail?
A: No. You can connect one account per connector: each connector maps to a single authenticated account, recorded against your workspace and user. To use a different account, disconnect the current one and connect the other.
Q: Can my organization restrict which workspace or tenant users connect to — for example, only our corporate Slack?
A: For most connectors, no. There is no general setting that locks a connector to a single corporate tenant. It is possible only for connectors that support a custom OAuth app with a tenant ID — primarily the Microsoft connectors such as Teams and SharePoint. For the rest, including Slack, there is no per-tenant restriction today.
Q: Do we need to configure our identity provider (IdP) or register an OAuth app to use connectors?
A: No. Your IdP is only used to sign you in to Sana. Connectors use Sana's own managed OAuth apps: when you connect an application, you sign in to it with your own account and approve the requested permissions. Nothing is set up in your IdP and no callback URL needs registering. The one exception is the tenant restriction described above, which some Microsoft connectors support through your organization's own OAuth app.