The Sidepanel does not load for a shared mailbox

Most Sidepanel loading failures in the Outlook app happen on shared mailboxes, and nearly all of them come down to how the mailbox was added to Outlook rather than to anything in Tekst.

This article is written for a Microsoft 365 administrator, because every fix below needs admin rights. If you are the person seeing the problem, send this article to whoever manages your Microsoft 365 tenant.

Before working through it, confirm the basics covered in The Sidepanel does not load in the Outlook app: an email has to be open, and Tekst has to be reachable from the machine.

The three causes, most common last

Run the three checks below. The third one, automapping, is the cause we see most often.

1. The mailbox is hidden from the address list

If the shared mailbox is hidden from the Global Address List (GAL), the panel cannot resolve it and fails to load.

Fix (Microsoft 365 administrator):

• Open the Exchange admin center at admin.exchange.microsoft.com.
• Go to Recipients > Mailboxes and select the shared mailbox.
• Turn off Hide from my organization's address lists (also shown as "Hide from address lists") and save.
• Alternatively, run this in Exchange Online PowerShell:

Set-Mailbox -Identity "sharedmailbox@yourcompany.com" -HiddenFromAddressListsEnabled $false

• Allow a short time for the change to propagate, then restart Outlook and reopen the panel.

2. The mailbox was added by signing in with its own password

A shared mailbox should be reached through delegated access, not by adding it as a separate account and signing in with a username and password for the mailbox itself. Direct password sign-in is not a supported or secure setup, and the panel does not work reliably with it.

Fix:

• In Outlook, remove the directly added account: File > Account Settings > Account Settings, select the shared mailbox account, and click Remove.
• Have a Microsoft 365 administrator grant the user access instead (see the automapping steps below), so the mailbox is added through delegation rather than a password.
• As a best practice, the administrator should keep sign-in blocked for the shared mailbox account. Shared mailboxes do not need their own password, and blocking sign-in is more secure and keeps every action tied to the individual user who performed it.

3. The mailbox was not added through automapping

This is the most common cause. When an administrator grants a user Full Access to a shared mailbox, Outlook normally adds it automatically through automapping. Mailboxes added this way work with the panel. As a rule of thumb, if the user could open the mailbox through their normal permissions, the panel will work.

Problems appear when the mailbox was added by hand as an extra account (automapping off) instead of appearing automatically. Some teams do this deliberately to keep the local Outlook cache (OST file) from growing, but the panel does not load reliably in that setup.

Fix:

First, as a Microsoft 365 administrator, grant the user Full Access with automapping enabled. Either of these works:

• Microsoft 365 admin center (no Exchange admin role needed): go to admin.microsoft.com and open Teams & groups > Shared mailboxes. Select the mailbox, and under the members section click Edit to add the user. Adding a member this way grants Full Access and turns on automapping at the same time.
• Exchange admin center or Exchange Online PowerShell (useful for bulk changes or when you need to confirm automapping explicitly):

Add-MailboxPermission -Identity "sharedmailbox@yourcompany.com" -User "user@yourcompany.com" `
    -AccessRights FullAccess -AutoMapping $true

• If Full Access was previously granted with automapping turned off, remove it and add it again with automapping enabled:

Remove-MailboxPermission -Identity "sharedmailbox@yourcompany.com" -User "user@yourcompany.com" `
    -AccessRights FullAccess
Add-MailboxPermission -Identity "sharedmailbox@yourcompany.com" -User "user@yourcompany.com" `
    -AccessRights FullAccess -AutoMapping $true

• If Full Access was granted through membership in a security group rather than to the user directly, automapping never happens, no matter how long you wait or how often Outlook is restarted. Grant Full Access to the individual user's mailbox instead of the group.

Then, the user needs to make Outlook pick up the change:

• If the shared mailbox is currently added by hand (as its own account, or listed under the account's advanced "additional mailboxes" settings), remove that copy first so it does not conflict with the copy added through automapping.
• Fully close Outlook (exit completely, not just close the window) and reopen it. Outlook only rebuilds its mailbox list on startup, so a permission change granted while Outlook is running will not appear until it restarts.
• Permission changes can take a while to reach Outlook. If the mailbox still does not appear after a restart, wait and restart Outlook again.
• If it still does not appear, ask IT to recreate the Outlook profile (Control Panel > Mail > Show Profiles). This forces Outlook to run Autodiscover again and pick up the newly granted access.

Once the mailbox appears under the user's own account, select an email in it and open the Tekst panel to confirm it loads.

If you turned automapping off to control the size of the OST cache, see Slow shared mailboxes - cause and solution for other ways to keep the cache under control while keeping automapping on.

Using the new Outlook for Windows? A shared mailbox added through automapping shows up under Settings > Accounts > Shared with me rather than as a full account, with a Convert option to promote it. You do not need to convert it for the panel: reading email in it works either way. Converting is only needed if the user wants to manage the shared mailbox's own account settings.