The Problem We Are Solving
If you have ever tested a flow and watched the email arrive from your own name instead of the HR, finance, support, or invoices mailbox, the flow has not really passed the business test yet.
The awkward part is that Power Automate can succeed and still be wrong for the team. The message may come from the account behind the Outlook connection, replies may land with the maker, or the sent copy may be somewhere the rest of the team cannot see.
Here is the plain-English choice. Send As means Exchange lets the shared mailbox appear as the sender. Shared Mailbox V2 means the Power Automate action called Send an email from a shared mailbox (V2). Mailbox auto-reply means the mailbox itself sends a standard automatic reply without a flow. The right choice depends on what the email is for, who should receive replies, what permission IT is willing to grant, and where the sent evidence needs to live.
The Short Answer
For official department notifications that need flow data, start with Send an email from a shared mailbox (V2) if the team needs the message to come from the shared mailbox and appear in that mailbox's Sent Items.
Use Send an email (V2) with From (Send as) when your admin wants a send-only pattern and can grant the connection account Send As or Send on behalf without also granting Full Access. That can keep mailbox-content access out of the flow account, but only if your admin confirms the permission pattern in your tenant. If you choose this route, do not stop after the email arrives. Check where the sent copy is saved, because delegate-sent messages may need Exchange Sent Items copy settings.
Use mailbox automatic replies when the job is only a simple, mailbox-level acknowledgement such as "we received your message". If the message needs SharePoint data, approval status, conditional wording, attachments, or different routing, it has become a Power Automate job again.
Leave the sender as the connection account only when the email is meant to come from that person or from a monitored automation/service account. It is not the right default for official team mail.
What The Options Mean
Connection account means the Microsoft 365 account used by the Office 365 Outlook connection in the flow. When a flow sends email through Outlook, Exchange cares about that account's mailbox permissions.
Send an email (V2) is the standard Office 365 Outlook action for sending mail from the connection account. Its advanced From (Send as) field can send from another mailbox only when the connection account has the right Exchange permission.
Send an email from a shared mailbox (V2) is the dedicated Power Automate action for sending from a Microsoft 365 shared mailbox. Microsoft describes it as the action to use when specifying a shared mailbox address, with permission to that mailbox required first.
Send As makes the message look as if it came directly from the shared mailbox. The recipient does not see the delegate in the From line.
Send on behalf is more transparent. The recipient sees that one account sent on behalf of the mailbox.
Full Access, also shown as Read and manage, lets a delegate open and manage mailbox contents. It does not, by itself, grant sending rights. This matters because giving a flow account Full Access just to send an email may be more access than the process needs.
Sent Items copy settings are Exchange settings that control whether messages sent as or on behalf of a mailbox are copied into that mailbox's Sent Items. Without the right setting, the team may not find the sent record where they expect it.
Mailbox automatic replies are configured on the mailbox itself, outside Power Automate. They are best for simple standard replies, not for messages that need flow data or branching.
Practical Options
| Option | Best fit | What recipients see | Permission/admin need | Sent Items check | Watch out for |
|---|---|---|---|---|---|
| Send an email (V2) with From (Send as) | You need a send-only Power Automate email from a shared address | Shared mailbox with Send As, or "user on behalf of mailbox" with Send on behalf | Admin grants Send As or Send on behalf to the connection account; Full Access is separate | May save to the connection account unless shared mailbox copy settings are configured | The From field is not magic text; missing permission usually causes a send failure |
| Send an email from a shared mailbox (V2) | Official team notifications where the team expects a shared Sent Items trail | Shared mailbox | Admin must give the connection account permission to the shared mailbox | Microsoft's email scenario guidance says this action appears in the shared mailbox Sent folder | Confirm what mailbox access your admin grants, especially if a named user's account is used |
| Mailbox automatic replies | Static acknowledgements from the mailbox itself | Shared mailbox | Admin or mailbox delegate configures automatic replies | Treat as mailbox behaviour, not a flow-sent message trail | Too blunt for conditional or data-driven responses |
| Leave sender as connection account | Personal messages, or a deliberate monitored automation account | The connection account | No shared mailbox permission needed | Connection account Sent Items | Recipients may reply to the wrong person or distrust an official-looking process |
Recommended Move
For a normal department flow, write the decision down before you build:
This email represents the team, so it should send from the shared mailbox, replies should return to the shared mailbox, and the sent copy should be visible to the team.
That decision often points to Send an email from a shared mailbox (V2), provided IT is comfortable granting the required shared mailbox access to the flow's connection account.
If IT says the flow account should not be able to open the mailbox, ask whether a Send an email (V2) + From (Send as) pattern is acceptable instead. That can support a least-privilege send-only design, but it needs a specific Send As or Send on behalf permission and a separate check for the Sent Items trail.
If the whole requirement is a generic receipt message, do not build a flow just to prove you can. Use mailbox automatic replies and keep the automation budget for the cases that need logic.
If the email can safely come from the maker or a monitored service account, leave the sender alone. Just make that an explicit decision, not the accidental result of the first successful test.
One-Page Decision Record
Copy this into the ticket, flow notes, or admin request.
| Field | Decision |
|---|---|
| Business message | What is this email telling the recipient? |
| Sender should appear as | Shared mailbox / named person / service account |
| Replies should go to | Shared mailbox / named person / monitored service account |
| Chosen Power Automate route | Send an email (V2) with From / Send an email from shared mailbox (V2) / mailbox automatic replies / connection account |
| Connection account | The account used by the Outlook connector |
| Permission needed | Send As / Send on behalf / Full Access / none / admin to confirm |
| Sent Items expectation | Shared mailbox / connection account / both |
| Privacy note | Does the connection account need to read mailbox contents, or only send? |
| Test recipient | Safe internal account used before real recipients |
| Pass test | Sender display, reply path, and Sent Items location all match the decision |
Admin Request Wording
Use plain wording. It saves three rounds of clarification.
We are building a Power Automate flow that sends official messages for [team/process] from [shared mailbox address]. The Outlook connector will run under [connection account]. Please confirm the safest supported pattern and grant only the permission needed for that pattern.
Required result: recipients see [desired sender], replies go to [reply mailbox/account], and sent copies are visible in [expected Sent Items location]. If we use Send As or Send on behalf, please also confirm whether the shared mailbox Sent Items copy setting needs to be enabled.
Evidence Notes
Use Microsoft documentation to trust the mechanics. Do not use it as proof that your tenant is already configured correctly.
- Microsoft Power Automate guidance supports the two action families: the standard Send an email (V2) action and the dedicated Send an email from a shared mailbox (V2) action. It also says the shared mailbox action needs permission to the mailbox first.
- Microsoft Exchange documentation separates Full Access, Send As, and Send on behalf. Full Access is mailbox access; it is not the same as sending permission.
- Microsoft Exchange Sent Items guidance explains why a message sent by a delegate may not land in the shared mailbox Sent Items folder unless copy behaviour is configured.
- Microsoft 365 admin guidance supports configuring shared mailbox automatic replies and Sent Items settings in the admin center.
- 2026 Power Platform community threads show the lived problem: makers hit Send As permission failures, emails come from the flow connection identity, and teams struggle to find shared mailbox sent records. Treat those as warning signs to test your tenant, not as universal product guarantees.
Proof Boundary
Use this as a decision record starter, not as proof that your tenant is configured correctly. The final answer still depends on your mailbox permissions, Outlook connection, conditional access rules, and live test results.
Before the flow goes near real recipients, run one internal test and capture three facts: the From line, the reply destination, and the Sent Items location.
Source note
Briefing published by Collab365 Spaces, reviewed by Helen Jones on . Cite as "Choose Send As, Shared Mailbox V2, or Mailbox Auto-Reply", Collab365 Spaces. 10 sources referenced.