> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/administer-and-govern/control/connections/outlook.md). # Outlook Connect Microsoft Outlook for email and contact work, including delegated or shared mailboxes when the Microsoft-side permissions and Lleverage scopes are in place. Outlook Connections let the Agent and Workflows work with Microsoft 365 email and contacts using an authorised Microsoft identity. The Connection controls **which Microsoft identity Lleverage can act as**. The action or Skill using that Connection controls what operational work is performed. ## Connect an Outlook account Open **Control → Connections**, choose **Microsoft Outlook**, select the actions the Connection may use and complete the Microsoft sign-in flow. If the Microsoft tenant requires administrator consent, that approval remains a Microsoft-side prerequisite. Completing delegation or consent in Microsoft does not create a Lleverage Connection by itself. For automated service identities, Outlook also supports **App Registration (S2S)**. In that flow an administrator provides the Azure application Client ID, Client Secret and Tenant ID rather than connecting an individual user account. ## Shared and delegated mailboxes A delegated Outlook Connection can work with mailboxes other than the signed-in user's mailbox, but there are two separate gates: 1. Microsoft Exchange must already grant the signed-in user access to the mailbox. 2. The Outlook Connection must have the additional shared-mailbox OAuth scopes enabled in Lleverage. To enable the second gate, expand the Outlook Connection in **Control → Connections**, open **Agent actions**, find **Shared mailbox access** and choose **Enable shared mailbox access**. The additional scopes are added to the existing Connection; they do not grant Exchange access themselves. ### Address each mailbox explicitly Outlook actions and supported triggers that can target another mailbox use a **target user** address. Supply the mailbox's primary SMTP address, for example `finance@example.com`. Lleverage does not currently discover or list all mailboxes to which a user has delegate access, and the target-user field is not validated against a mailbox picker. An incorrect address therefore fails when Microsoft Graph handles the request. This means an IT team setting up several shared mailboxes should provide the actual SMTP addresses as part of the setup. ### Full Access and Send As are different Reading or managing a shared mailbox normally depends on the appropriate Exchange mailbox delegation, such as Full Access. Sending **from** that mailbox can require a separate Send As or equivalent Exchange grant. Lleverage does not create either permission. ## When S2S is a better fit Use an Azure App Registration when the intended operating model is a service connection with tenant-level application permissions rather than a user delegated across individual mailboxes. That can be a better fit for high-volume or centrally managed back-office processes, but it also gives the application a different and potentially broader authority. Keep the Azure application permissions and the actions enabled on the Lleverage Connection aligned with the use case. ## Shared-mailbox opt-in applies to Outlook email The current **Shared mailbox access** opt-in belongs to the Outlook email provider. Microsoft Outlook Calendar has its own Connection and does not inherit this shared-mailbox scope upgrade. See [Microsoft Outlook Calendar](/administer-and-govern/control/connections/microsoft-outlook-calendar.md). ## Troubleshooting When Outlook works for the signed-in mailbox but not another mailbox, check these separately: * the Connection is active and uses the expected Microsoft identity; * **Shared mailbox access** has been enabled when using delegated OAuth; * the mailbox address passed as target user is correct; * the signed-in identity has the required Exchange delegation; * Send As permission exists when the operation sends from that mailbox; * Microsoft administrator consent has been granted if the tenant requires it. Do not work around an Outlook permission problem by copying Microsoft credentials into a Skill, Workflow, Variable or file. Keep authority in the Connection and in Microsoft Entra/Exchange. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lleverage.ai/administer-and-govern/control/connections/outlook.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.