Multi-user “Send email with options” connections become invalid after disabling flow

(0) Share

Report

Posted on by V_Tiger

Hi!

I built a Power Automate flow triggered when a file is saved in SharePoint by one of three team members.

Based on an upstream condition, the flow emails the file as an attachment to three SMEs for review/approval:

PMD (varies)
Vision SME (always the same)
Dental SME (always the same)

Each SME responds using the option buttons in Send an email with options.

Because we need the email to come from the person who saved the file, I used Send an email with options and, in each person’s branch/path, I set that action to use that team member’s Outlook connection. Testing worked as expected (e.g., when I saved the file, the email came from me; when team member 2 saved it, it came from her; etc.). I have a flow-chart screenshot showing this setup.

However, after turning the flow off for a few weeks and then turning it back on, I started getting errors that all connections are invalid. My teammates’ connections appear to have been removed/erased. When I try to add them back, I can only add my connection—not theirs. I’ve included a screenshot of the email actions showing the connection errors.

Question: How can I keep these “send as the saver” connections from being removed/invalidated when the flow is turned off (which we do annually)? Is there a way to make the connections persist, or a better pattern to avoid having to re-add teammates’ connections each time? Thanks in advance!

Categories:

Building flows

I have the same question (0)

All responses (2)

Answers (0)

Sort by

Pstork1 69,323 Most Valuable Professional on at

Like (3)

Report
Copy link

Link copied!

The problem is that connections are created using OAuth authentication. That authentication has to be renewed every 30 days. So after turning off the flow for a few weeks the other connections expired and since they weren't associated with your account they were removed. You will need the user's involved to create new connections for you. But those will also disappear after 30-90 days and need to be recreated. Power Automate simply isn't designed to send Emails in the fashion you are describing.

----------------------------------------------------------------------------------
If this Post helped you, please click "Does this answer your question" and give it a like to help others in the community find the answer too!

Paul Papanek Stork, MVP
Blog: https://www.dontpapanic.com/blog

Was this reply helpful? Yes No
Sunil Kumar Pashikanti 1,681 Moderator on at

Like (1)

Report
Copy link

Link copied!
Hi @V_Tiger,

The behavior you’re seeing, where Outlook connections appear to “drop” after a flow has been disabled for months, is expected behavior in Power Automate. Connections are user‑owned OAuth tokens as mentioned by @Pstork1, not long‑lived system assets.

Why this happens
Token expiration:
User connections rely on OAuth refresh tokens. When a flow is turned off for an extended period (weeks or months), those tokens can expire or be invalidated by tenant security policies.
Owner‑only rebinding:
The Flow designer can only bind connections owned by the current editor. It cannot re‑authenticate or recover connections created by other users who are not actively editing the flow.
Orphaned metadata state:
Disabling a flow for long periods effectively freezes its configuration. When re‑enabled later, previously valid user connections may no longer be trusted or resolvable.

Recommended Solution: Use a Service Account Model
For seasonal or long‑lived flows, avoid user‑specific email connections.
1. Use a service account or shared mailbox (best practice)

Create a single Outlook connection using a service account or shared mailbox

Use “Send an email from a shared mailbox (V2)”

This connection remains stable regardless of who saves files or turns the flow on/off

2. Handle the user identity dynamically

Capture the file creator using trigger metadata

Include it in the email body (for example: “Submitted by: ”)

This avoids dependency on the sender identity

3. “Send As” scenarios (not recommended)
While it is technically possible to grant Send As permissions, this is high‑maintenance and fragile at scale. A shared mailbox approach is far more reliable for production and seasonal flows.

Summary

Individual Outlook connections are intended for personal workflows
Long‑disabled flows will eventually lose user‑owned connections
A service account or shared mailbox is the correct enterprise pattern
This avoids annual reconfiguration and connection breakage

Bottom line: Your original design worked functionally, but it isn’t durable. Switching to a single, non‑user‑owned connection is the supported and stable solution.

Was this reply helpful? Yes No