## TL;DR
Deploy and pin the reporting add-in for the shared mailbox context, not just for individual users: check that the Microsoft Report Message or Report Phish add-in is deployed organisation wide or to the group that staffs the shared mailbox, confirm the new Outlook add-in surface is enabled, and test while acting as the shared mailbox, because add-ins that appear in a personal mailbox routinely vanish in delegated and shared contexts when deployment was scoped to users only.

```text
report phish add-in button missing in the new outlook for shared mailboxes
```

## Use this when
- The Report Phish or Report Message button appears in personal mailboxes but not when working in a shared mailbox in the new Outlook.
- Support staff triage reports from the shared mailbox daily.
- Other add-ins may also be missing in the same shared context.

## Not for this skill when
- The button is missing everywhere for all users. That is a tenant deployment or licensing problem.
- Users need to report mail in a third party client. The Outlook add-in will not appear there at all.

## Steps
1. Reproduce the problem yourself by opening the shared mailbox in the new Outlook and checking the message ribbon and the add-in list. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the missing button is confirmed in the shared context specifically
2. Review the add-in deployment in the Microsoft 365 admin centre: assignment scope, user groups, and whether the add-in is set to optional or fixed. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the deployment scope is recorded and any gap for the shared mailbox team is visible
3. Extend deployment to the team that staffs the shared mailbox and confirm their permissions on the mailbox include reading and acting on messages. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the deployment shows the team in scope and mailbox permissions are confirmed
4. Restart the client, open the shared mailbox again, and open a test message. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the report button is present in the shared mailbox view
5. Send a test report from the shared context and confirm it lands in the expected submissions mailbox or portal. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the test report is received at the triage destination

## Why it happens
Add-ins in the new Outlook render per identity context, and shared mailboxes are a second context with their own rules. A deployment that works for a user own mailbox can still leave the shared view bare if the assignment, the mailbox permissions, or the client add-in setting do not cover acting as the shared mailbox. Support workflows built around a shared triage mailbox feel this first, because that is exactly where the reporting button matters most.

## Variants and edge cases
### report phish add-in button missing new outlook shared mailbox
The exact client and mailbox context phrasing.
### report message add-in not showing shared mailbox deployment scope
The deployment scope variant for admins.
### users cannot report phishing from shared mailbox outlook new
The user workflow variant in plain words.

Compatibility: Microsoft 365 add-in deployment, Report Message and built in reporting in the new Outlook and Outlook on the web.

Edge cases to check:
- The built in Report button in Outlook on the web may cover the need without any add-in; compare both before deploying.
- Pin guidance for staff matters: an installed but unpinned add-in is effectively missing during a busy triage shift.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nEis7ec_hBNKzS9eWEn6jA