Choose the process before the tool
You do not integrate "the CRM". You integrate what is needed to prepare a follow-up or qualify a request. The process determines access, never the other way round.
Connecting an AI to your emails, calendar, CRM and documents is rarely a technical problem. It is a problem of scope, permissions and validation. Here is how we handle it.
Integrating AI into a company means giving it delegated, limited and revocable access to specific tools — mailbox, calendar, CRM, document storage — then defining, for each action, whether the agent may act alone or must submit its work for validation. The technical connection uses delegated authorisation from your existing accounts: no password is transmitted and access stays revocable at any time. The real difficulty is not the connection, but writing the rules and handling exceptions.
Each family raises a different risk question. Handling an email does not commit the company the way writing into a CRM does.
| Tool family | Read | Possible action | Our recommendation |
|---|---|---|---|
| Mailbox Gmail, Outlook, IMAP | Defined inbox or folder | Draft, sorting, reply | Sending under validation at first |
| Calendar Google Calendar, Outlook | Availability | Proposal, creation, update | Autonomous creation possible, cancellation not |
| CRM HubSpot, Pipedrive, Notion | Records and history | Note, task, follow-up update | Financial fields read-only |
| Documents Drive, SharePoint, Notion | Authorised folders | Generation, draft deposit | Never deletion or overwrite |
The full connector list and status are on the Sania integrations page. For an internal tool without a standard connector, see custom AI agents.
You do not integrate "the CRM". You integrate what is needed to prepare a follow-up or qualify a request. The process determines access, never the other way round.
For each step, which information is indispensable? Anything unnecessary should not be accessible. This is also the basis of the minimisation principle under the Swiss FADP.
Connection from your Google Workspace, Microsoft 365 or CRM accounts, with a chosen scope. No shared password, no generic account, revocable at any time.
For each action: autonomous, requires validation, or forbidden. It is the most useful document of the project, and the most often skipped. See our approach to security.
The agent prepares, nobody sends. Compare its work with a colleague's on the same files, including the awkward ones.
Grant autonomy where errors are reversible and detectable. Refuse it elsewhere, however convincing the demo was.
Sort, prioritise, retrieve client context and prepare a reply in the authorised mailbox, without sending without approval.
AI assistant for emails →Read availability, apply your slot preferences and prepare invitations.
AI-assisted calendar →Retrieve a contact's history, write a follow-up note, create a task and flag dormant deals.
AI sales follow-ups →Turn a request into a structured draft from your authorised services, flagging what is missing.
Creating quotes with AI →A broad scope becomes impossible to audit and blocks any later compliance discussion.
Each integration adds a dependency to maintain and a source of error. One is enough to find out whether the process works.
One wrong message to a client costs more than a week of saved time.
You lose individual traceability, and with it the ability to explain an action afterwards.
How do you revoke access, export configurations and stop the service? Decide before, not during an incident.
Through delegated authorisation: you grant access from your Google Workspace or Microsoft 365 account, choosing the scope of rights. No password is shared, authorisation is revocable at any time from your admin console, and scope can be limited to a mailbox, folder or label.
No, and we advise against it for a first deployment. Restrict it to a functional mailbox, a folder or a period. Start with the narrowest scope that still handles the use case, then widen if results justify it.
Yes, if writing is explicitly authorised. Separate read, create and update rights, then distinguish what the agent does alone from what requires validation. A follow-up note can be automatic; changing an amount or deleting a record should not be.
For common tools with a standard connector, the technical connection is quick. The real project time is elsewhere: defining rules, exceptions and validation points. That step decides whether the system will be usable and cannot be compressed.
Often yes, but that is a custom project rather than a few-clicks connection. Feasibility and cost depend on available access points and data quality. See custom AI agents.
An integration is a dependency to monitor. Third-party changes are part of maintenance and can alter a behaviour or break a connection. One more reason to limit integrations to those delivering measurable value.
It depends on the components used and must be documented before go-live: application hosting, where model processing happens, sub-processor list, retention periods. This belongs in project documentation. See security and data.
Not for standard connections, which are made from your usual admin interfaces. However, the person who knows the process must be available: they, not an IT specialist, hold the rules to be modelled.
One conversation is usually enough to know whether the integration is simple, complex or pointless.