Microsoft, Slack and Messaging

Outlook and Microsoft 365

OAuth, from the Integrations tab. It covers mail and calendar, and it behaves like the Google equivalents: mail appears in the Email Inbox behind its provider tab, events appear in the unified calendar, and the agent gains the corresponding capabilities.

If your organization runs Microsoft, this is your equivalent of the Google lesson: connect calendar and mail first, and read the consent screen.

One organizational note: some Microsoft tenants require admin consent for third-party applications. If the connect flow ends with a message about needing approval, that is a tenant policy rather than a Kavanah problem, and it is resolved by your Microsoft administrator rather than by retrying.

Slack

Slack connects by OAuth and is worth connecting for most teams, because Slack is where the conversation actually is.

What it gives you depends on the scopes granted, and history scopes in particular are what make it useful for anything retrospective. A Slack connection that can post but cannot read history is a notification channel rather than an integration.

The decision worth thinking about is whether you want Kavanah reading Slack or your team moving conversation into Kavanah's own Messages. Both are legitimate. Connecting Slack is much less disruptive and gets you most of the value; moving is better if your goal is to have work and conversation in one place. Doing half of each — some conversation moved, Slack still connected — is the outcome to avoid, because now nobody knows where to look.

ProtonMail and iCloud

These two are worth calling out because they are not plain OAuth.

ProtonMail connects through Bridge — Proton's local application that exposes your mailbox over standard protocols. That means Bridge has to be running and configured; the connection is against Bridge rather than against Proton's web service directly.

iCloud uses an app-specific password rather than your Apple ID password. Generate one in your Apple account settings and use that. This covers Apple Mail, iCloud Calendar and Contacts, over the standard protocols.

Both work well once set up. Both have a first-time setup that is more than clicking Connect, which is why they surprise people who expect the Google flow.

Telegram

Telegram connects as a messaging channel. It is most useful as a delivery route — a place to receive something rather than a corpus to read — and it is worth connecting if it is where you or your clients actually are.

The general principle applies: connect a channel because a real conversation happens there, not because the card exists.

Choosing what to connect

The test for any messaging integration is whether commitments are made there.

If your team agrees work in Slack, connecting Slack means those agreements can become tasks. If Slack is only for social chat and the real decisions happen in meetings and mail, connecting it adds noise to whatever reads it.

So the honest audit is: where does someone say 'I'll do that by Friday'? Connect those places. Leave the rest.

This matters more than usual because captured task candidates come from conversation, and a capture source full of chatter produces a triage queue full of dismissals — which is the fastest way to make people give up on the triage queue entirely.