Power Automate Shared Mailbox Trigger Not Firing? Diagnose It Properly

An email reaches the shared support inbox. Humans can see it in Outlook, but the Power Automate flow never runs.

Is it just you? No. The Office 365 Outlook connector has documented limits around permissions, folders, protected messages, message size and attachments. But that does not mean the shared-mailbox trigger is universally broken or that forwarding every message to another mailbox is automatically safer.

The right response is:

1. prove whether the trigger failed or the flow failed later;
2. check the documented failure modes in a controlled order;
3. use one trigger for each mailbox;
4. add idempotency and reconciliation if losing a message would matter.

The current shared trigger is When a new email arrives in a shared mailbox (V2). There is no shared-mailbox V3 trigger in the current Office 365 Outlook connector reference.

The short answer

Start with the native V2 trigger for one shared mailbox. The trigger's required Original Mailbox Address field is a single string, so use a separate ingress flow for each mailbox rather than trying to pass an array.

Keep each ingress flow small. Record which mailbox and message arrived, claim an idempotency key, then hand the work to shared processing logic.

If the process is business-critical, do not treat any email trigger as a durable queue. Add an overlapping scheduled check that finds messages not recorded by the ingress flow. For large-scale application integration, use Microsoft Graph change notifications with lifecycle and delta recovery—not a webhook alone.

Situation	Sensible starting point
One shared mailbox, ordinary internal process	Native V2 trigger with the checks below
Several shared mailboxes using the same processing	One small trigger flow per mailbox, then a common child flow or queue
Missing one email would breach a customer or operational commitment	Native ingress plus a durable ledger, alerts and scheduled reconciliation
Many mailboxes or an application-owned integration	Graph change notifications, scoped application access, lifecycle events and delta recovery
Forwarding is already an approved mail-routing policy	Treat it as a deliberate Exchange design, not as a quick trigger fix

First: did the trigger fail, or did the run fail?

These are different incidents.

• No run exists: investigate the trigger, connection, mailbox, folder and trigger filters.
• A run exists but failed: the email was detected. Investigate the first failed action, its inputs, retries and downstream permissions.
• A run succeeded but the business result is missing: inspect conditions, branches, duplicate checks and destination writes.

Open the flow's run history and compare it with a test message's received time. Microsoft's trigger troubleshooting guide also tells you to inspect trigger conditions, connections, permissions, data-loss-prevention policy and disabled flows.

Do not redesign the mailbox because a SharePoint Create file action received an empty attachment. That is a downstream data problem, not proof that the trigger never fired.

Eight checks for the shared-mailbox V2 trigger

1. Confirm the trigger and mailbox address

The trigger should be When a new email arrives in a shared mailbox (V2) from the Office 365 Outlook connector.

Check Original Mailbox Address carefully. It must resolve to the intended shared mailbox. Microsoft's connector troubleshooting says to verify this address, re-check the shared mailbox configuration and recreate the Outlook connection when the object cannot be found.

Start with a literal mailbox address while diagnosing. Add environment variables or deployment indirection only after the simple version works.

2. Check the identity behind the Outlook connection

The shared mailbox does not sign in to the connector. A user connection accesses it.

That connection identity must be a member of the shared mailbox and have the access needed to read it. Send As is an outgoing-mail permission; it is not a substitute for mailbox read access. Microsoft explicitly notes that user-to-user shared mailboxes need Full Access for this trigger scenario.

Test with the same identity in Outlook on the web. If the person cannot open the mailbox and folder there, Power Automate is not the first problem to fix.

Also check Conditional Access and whether the connection token has expired. If you replace a connection, reselect it in the trigger and save the flow.

Do not solve ownership by sharing one user's password around the team. Microsoft's Power Automate licensing FAQ describes shared service-account credentials as a security and audit risk. Choose flow ownership, connections and licensing with your administrator, then document the handover path.

3. Check the folder and every Inbox rule

The trigger checks the folder selected in the flow. It does not watch the whole mailbox and follow a message wherever a rule moves it.

Microsoft documents two awkward consequences:

• an Inbox-configured trigger is not expected to fire for a message that a rule moves to another folder;
• later moves can behave inconsistently because the trigger uses the message's received date rather than treating the move as a new arrival.

For a clean test, disable the relevant rule or configure the trigger for the actual destination folder. Send a brand-new message after saving the flow. Moving an old message into the folder is not a valid new-mail test.

4. Remove trigger filters, then restore them one at a time

Temporarily clear To, CC, To or CC, From, Importance, Only with Attachments and Subject Filter.

Send a plain internal message with a unique subject. If that works, restore one filter and test again. This exposes a filter mismatch without changing the wider architecture.

Use filter fields in the trigger when they are genuinely stable. Microsoft's email-trigger guidance explains that trigger-level filtering avoids unnecessary flow runs. The useful rule is to filter deliberately—not to fill every available field.

5. Treat attachments as a separate design decision

The two attachment settings do different jobs:

• Only with Attachments decides whether messages without attachments trigger the flow.
• Include Attachments decides whether attachment content bytes are included in the trigger output.

Microsoft's shared-mailbox attachment troubleshooting says that downstream actions receive null content bytes when Include Attachments is No. Setting it to Yes supplies the bytes.

However, the connector's known-issues section also warns that downloading attachments inside an email trigger can time out under attachment load. A safer busy-mailbox pattern is:

1. let the trigger identify the message;
2. iterate the attachment metadata;
3. use Get Attachment (V2) with the Message Id, Attachment Id and Original Mailbox Address;
4. write the file only after checking the returned content.

That is not a guarantee for every attachment. The connector does not support every item-attachment type, and the trigger documentation says oversized, protected or invalid messages can be skipped.

6. Test protected and unusual messages separately

The connector says encrypted messages can return a secured-content note rather than the actual body. It may also skip protected messages or messages with invalid bodies or attachments.

Do not let the flow assume every message has readable HTML, a normal attachment or a populated body. Add a branch that records unsupported content and alerts a human without copying sensitive text into a broad notification.

Your test set should include:

• a plain internal message;
• a normal external message;
• a small file attachment;
• a message routed by an Inbox rule;
• a protected or encrypted message if your organisation uses them;
• a message with the same subject as an earlier message.

The expected result for a protected message may be an exception path, not automated processing.

7. Inspect trigger conditions and flow state

Open the trigger's Settings tab and inspect Trigger conditions. A valid-looking expression can suppress every event before a run is created.

Also confirm:

• the flow is turned on;
• it is in the expected environment;
• the owner and connection references are healthy;
• no data-loss-prevention policy has suspended it;
• the flow has not been disabled by an administrator or after an unresolved platform error.

After changing a trigger or connection, save it and send a new test message. Do not use an existing message as proof.

8. Separate connector throttling from guessed data loss

The Office 365 Outlook connector publishes throttling limits, but a burst of mail is not enough evidence to declare that the trigger silently discarded a batch.

Look for actual connector errors, delayed runs and failed downstream actions. Measure your mailbox volume and run history. If a process cannot tolerate uncertainty, add reconciliation rather than publishing a guessed uptime percentage.

The maintainable multi-mailbox pattern

One Power Automate flow has one trigger. The shared-mailbox trigger has one Original Mailbox Address. For three shared mailboxes, build three small ingress flows.

Each ingress flow should pass the same compact envelope to shared processing:

• mailbox address;
• connector Message Id;
• Internet Message Id when available;
• received time;
• sender and subject only if the process needs them;
• correlation or run id.

Put the flows in a solution and use connection references. If the shared logic is reasonably short, a child flow avoids copying the same processing steps. Microsoft requires parent and child flows to be solution-aware and documents how child-flow connections must be configured.

For slower or failure-prone processing, hand the envelope to a durable queue or work table instead. The ingress flow should finish after the message is safely recorded; retries and long-running work happen separately.

Claim the message before side effects

Create an idempotency key such as:

mailbox address + Internet Message Id

The mailbox matters because the same internet message can legitimately reach two shared mailboxes. Enforce uniqueness in the destination where possible. A Power Automate “Get items, then create” condition can still race if two runs check at the same time.

Only after the key is claimed should the flow create a ticket, save an attachment or send a response. Store the processing state and last error so that support can distinguish Received, Processing, Completed and Failed.

Add reconciliation when missing mail matters

The trigger is the fast path. Reconciliation is the recovery path.

Run a scheduled flow with an overlapping lookback window. For each mailbox, use Get emails (V3) with its Original Mailbox Address, retrieve a bounded set from the intended folder, and compare each result with the durable ledger.

The action's Search Query field uses Microsoft Graph $search; it is not an OData $filter box. Do not paste receivedDateTime ge ... into it and call the design complete. Use supported search syntax to narrow the lookback, then compare the returned Received Time in the flow and rely on the idempotency key to make overlap safe.

Microsoft's connector reference also warns that several ordinary Get emails filters operate on the first 250 messages in the folder. Search Query searches the folder, while Top still bounds the returned set. Test the design with the real mailbox volume and define what happens if the lookback contains more messages than one run retrieves.

For a low-volume team process, a controlled SharePoint list can act as the ledger. For a customer-facing or high-volume process, use a store and queue designed for concurrency, retention and operational queries.

When Microsoft Graph is justified

Microsoft Graph change notifications are an application integration, not a two-action Power Automate trick.

For Outlook messages in shared or delegated folders, Microsoft says delegated .Shared permissions do not support change-notification subscriptions. The application needs the corresponding application permission. Scope that access to the required mailboxes with Exchange Online RBAC for Applications instead of casually granting an app organisation-wide mail access.

A production design must:

• validate the notification endpoint and clientState;
• renew subscriptions before they expire;
• process reauthorization, subscription-removed and missed lifecycle events;
• fetch or decrypt the resource data safely;
• use message delta queries to recover and maintain per-folder state;
• monitor the endpoint, queue and subscription-renewal job.

Microsoft's Outlook change-notification guidance and lifecycle-event documentation make those requirements clear. A notification is a signal that something changed; it is not durable proof that your business process completed.

If Power Automate calls Graph through an HTTP or custom connector, check the current connector classification and licence context. Do not infer a universal Premium requirement from “Graph” alone, and do not assume the Office 365 Outlook connector grants an app the permissions needed for shared-mailbox subscriptions.

Should you forward everything to one mailbox?

Microsoft 365 can forward mail received by a shared mailbox. That can be appropriate when Exchange administrators deliberately want central routing.

It is not automatically a reliability upgrade. Forwarding changes the mail path and can affect retention, duplicate copies, security inspection, replies, original-recipient handling and operational ownership. External forwarding needs additional care.

If forwarding is approved, route on supported message properties or explicit metadata. Do not scrape To: and Subject: from the rendered email body with fixed string positions. Formatting, languages, forwarded-message layouts and missing labels will eventually break that expression.

Production acceptance test

Before calling the repair complete:

1. Record the connection identity, mailbox and configured folder.
2. Send each test-message type and record whether a run was created.
3. Verify attachment content by opening the saved file, not merely by seeing a successful action.
4. Move a new message with the real Inbox rule and verify the intended folder behaviour.
5. Force the downstream processor to fail and confirm the message remains recoverable.
6. Submit the same envelope twice and confirm only one business record is created.
7. Disable the trigger flow temporarily and prove that reconciliation finds the missed test message.
8. Confirm alerts identify the mailbox, message key, state and support owner without exposing unnecessary body content.
9. Replace or revoke a test connection and verify that the ownership runbook tells an administrator what to repair.
10. Record the tested limits and date as tenant evidence—not as a universal Microsoft guarantee.

Frequently asked questions

Can one shared-mailbox trigger monitor several mailboxes?

The current trigger has one required Original Mailbox Address string. Use one ingress flow per shared mailbox, then centralise the processing in a child flow or durable queue.

Why does the flow miss messages moved by an Inbox rule?

The trigger checks its configured folder and tracks received time. Microsoft says an Inbox-configured trigger is not expected to fire when a rule moves the message elsewhere, and later folder moves can produce inconsistent results. Configure the actual destination folder and test with new messages.

Should Include Attachments be Yes or No?

Use Yes when the flow genuinely needs content bytes in the trigger output and the tested load is acceptable. For a busy or attachment-heavy design, keep the ingress small and retrieve each file with Get Attachment (V2) using the shared mailbox address. Neither choice removes the connector's documented size, protected-message and invalid-content limits.

Is a service account mandatory for shared-mailbox flows?

No. The connector needs a permitted user connection, but Microsoft does not describe a shared-credential service account as mandatory and warns that shared service-account credentials create security and audit problems. Choose an owned connection and licensing model with your administrator.

Do Graph webhooks guarantee that no email is missed?

No. Graph change notifications require subscription renewal and lifecycle handling, and Microsoft provides missed-notification events and delta query for recovery. A resilient application treats the notification as a signal and keeps durable processing state.

Build the boring, supportable version

If your shared mailbox flow is dropping messages, bring the trigger settings, one missed-message example and the run history to the Power Automate Builders Space. The useful answer is usually less dramatic than “replace everything”—but it should leave you with a flow you can test, recover and hand over.