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 [e-mail].

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.

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.