How to detect missing shared-mailbox emails with Get emails (V3)

If a shared mailbox is supposed to receive a message every few minutes, Power Automate can alert you when that message stops arriving. The reliable pattern is:

search for the messages you care about;
calculate the time window separately;
filter the returned messages by their received time; and
alert only when the filtered array is empty.

Do not paste an OData expression such as receivedDateTime ge ... into the Search Query box. Microsoft documents that box as a mail search across the folder. Microsoft Graph mail search uses searchable properties such as subject and received, with Keyword Query Language (KQL) syntax. It is not the same thing as an OData $filter expression.

The corrected flow

This example checks a shared mailbox every five minutes and raises an alert when no P1, P2 or P3 email has arrived in the last 40 minutes.

1. Start with a scheduled cloud flow

Add a Recurrence trigger and run it more often than the failure window. For a 40-minute window, every five minutes gives you a useful balance between detection speed and unnecessary runs.

The schedule and the look-back window are separate settings. Running every 40 minutes does not guarantee you are checking exactly the previous 40 minutes, especially after delays or a failed run.

2. Calculate the cut-off time

Add a Compose action named Cut-off time and use this expression:

addMinutes(utcNow(), -40)

Power Automate's expression reference confirms that addMinutes() accepts a timestamp and a positive or negative number of minutes. Both utcNow() and the message's receivedDateTime are UTC-friendly, which avoids local daylight-saving surprises.

3. Search the shared mailbox

Add Office 365 Outlook – Get emails (V3) and configure:

Folder: Inbox, or the folder your rule moves these messages into
Original Mailbox Address: the shared mailbox address
Search Query: (subject:P1 OR subject:P2 OR subject:P3)
Include Attachments: No, unless the flow genuinely needs them

The Office 365 Outlook connector reference says that the normal To, Cc, From, Importance, attachment and Subject Filter fields are evaluated against the first 250 messages in the folder. Its Search Query field searches the whole folder instead. Microsoft Graph documents subject as a searchable mail property and supports KQL operators such as OR.

Treat the query above as a starting point, then test it against known messages in your own mailbox. If P1 can appear in unrelated subjects, use a more distinctive token such as subject:"[P1]", or add a sender restriction.

Do not add receivedDateTime ge @{...} to this box. receivedDateTime is a Graph message property used by OData filtering; the connector's Search Query box is a mail-search field.

4. Keep only messages inside the 40-minute window

Add Filter array.

For From, select the value array returned by Get emails (V3). If you need the expression form, it is normally:

body('Get_emails_(V3)')?['value']

In advanced mode, compare each message with the cut-off time:

@greaterOrEquals(
  ticks(item()?['receivedDateTime']),
  ticks(outputs('Cut-off_time'))
)

Action names affect their internal expression names, so select dynamic content where possible instead of retyping names blindly.

5. Test for silence

Add a Condition and use:

empty(body('Filter_array'))

If the result is true, send the alert.
If the result is false, end the flow or record a healthy check.

The empty(), length() and date functions used here are documented in Microsoft's workflow expression reference.

6. Make the alert useful

A Teams or email alert should include:

the mailbox and folder checked;
the expected subject token;
the UTC start and end of the window;
a link to the flow run; and
who owns the next action.

Do not send the same alert every five minutes for the same incident. Store an AlertOpen flag or incident ID in a durable location, suppress repeats while it is open, and send a recovery message when a matching email arrives again.

The better monitoring design: look for a heartbeat

There is an important flaw in the original P1/P2/P3 idea: no priority email might simply mean that nothing is broken.

If the real requirement is “tell us when the monitoring system has stopped working”, have the upstream system send a predictable heartbeat such as MONITOR-HEARTBEAT every ten minutes. Alert when that heartbeat is missing for 40 minutes.

That turns an ambiguous absence into a testable service-level rule:

expected signal: one heartbeat every ten minutes;
alert threshold: no heartbeat for 40 minutes;
recovery: first heartbeat after an open alert; and
evidence: last received time and flow run ID.

Use P1/P2/P3 monitoring only when the business process genuinely guarantees that at least one of those messages should arrive during every window.

Shared mailbox checks that commonly catch failures

Symptom	Check
No messages are returned	Confirm the connection user has access to the shared mailbox and that Original Mailbox Address contains the shared mailbox address.
The search finds old messages	Keep the date comparison in Filter array and inspect the actual `receivedDateTime` values in run history.
Busy mailbox misses a match	Narrow the Search Query with a distinctive subject and sender. Check the action's returned count against the busiest real 40-minute period.
Alerts repeat continuously	Store incident state and suppress duplicates until recovery.
The flow is throttled or times out	Reduce the response size and attachment handling first. For deeper diagnosis, see Power Automate API timeout errors: diagnose the 120-second limit.

Microsoft's connector troubleshooting guidance also recommends checking membership, permissions and the original mailbox address when a shared-mailbox operation cannot find the object.

What this solution does not claim

It does not prove that every Microsoft 365 licence includes every action. Connector availability, licensing and data-loss-prevention policy vary by tenant.
It does not make a mailbox a monitoring platform. For high-severity operational alerting, use an incident system with ownership, deduplication and escalation.
It does not guarantee that a broad search returns every conceivable message. Test the query and returned volume with representative mailbox traffic.
It does not require a raw Microsoft Graph HTTP call. Start with the supported Outlook connector and add custom integration only when the requirement justifies the extra security and support work.

Quick test before you rely on it

Send one known matching email to a non-production mailbox.
Run the flow and confirm the filtered array contains that message.
Temporarily shorten the window, wait for it to expire, and confirm exactly one alert is raised.
Send another matching message and confirm the recovery path clears the incident state.
Re-test after changing the shared-mailbox permissions or connection owner.

That is a much stronger proof than a green designer checkmark.

Official sources

Want to compare the design with other builders before putting it into production? Join the Power Automate Builders Space.