Sending email from a mailbox nobody can sign in to

A common setup is a shared mailbox that a Power Automate flow uses as the sender: a do-not-reply address, or just as often a notifications@ or accounts@ that exists for sending, not receiving, and that nobody actually signs into. Do-not-reply is just the example here; the actual condition that matters is that there's no interactive login for the account. In Dataverse this looks simple, but you can hit two errors. The second one can't be fixed by an admin in the normal UI. Here's how I got it working without raising a ticket.

The setup

• A queue is the "From" in the flow's Send Email action.
• Behind the queue are a mailbox record and a system user record. The mailbox holds the real delivery settings, even though the queue itself shows "None".
• The flow runs as the account that owns its connection, and that account is not the do-not-reply user.

Problem 1: the mailbox won't enable

The mailbox showed Pending Approval, and Test & Enable then failed with a message about a missing prvReadActivity privilege.

Fix:

1. An admin approves the mailbox. In the Power Platform admin centre this is under Settings > Email > Mailboxes > Approve Email.
2. Set Incoming = None and Outgoing = Server-Side Synchronization.
3. Run Test & Enable again. Outgoing should show Success. Incoming can stay "Not Run".

The privilege error appeared because incoming mail was set to server-side sync, which needs read rights for the owning user. A send-only mailbox doesn't need incoming mail, so no security role change was needed.

Problem 2: "The user selected in the From field does not have the option enabled to allow other users to send the email on their behalf"

This is the harder one.

• Sending as another user needs two things: the sender has a role with Send Email as Another User (prvSendAsUser) — for a flow, that's the flow owner or connection account — and the From user has switched on the "allow other users to send email on my behalf" option.
• The second option isn't on the user or mailbox record. It lives in that user's own Personalization Settings, on the Email tab.
• Admins can't set it for someone else in the UI, and a no-login service account is exactly the account nobody can sign into to tick it themselves.
• Under the hood it's the issendasallowed column on the user's settings record.

Fix: set it by impersonation

The service account had no security roles, so impersonating it failed with "has not been assigned any roles… need prvReadUserSettings". Impersonation only carries the privileges of the user being impersonated, so an account with nothing assigned can't be impersonated at all yet.

1. Temporarily give the service account a role.
2. As someone with prvActOnBehalfOfAnotherUser (System Administrator has it), impersonate that user and set issendasallowed = true on their user settings.
3. Remove the temporary role. The flag stays set.
4. Test manually: create an Email, set From to the queue and To to your own address, then Send. It should arrive and show as Sent.

The service account ends up with no roles, as before, and only the one flag changed.

I did step 2 with the Level Up extension (the XrmToolBox-style impersonation tool), which is the quickest no-code route if you have it. The same thing is reachable directly through the Dataverse Web API, which is worth knowing if you need to script this across environments or don't have Level Up available.

PATCH [Organization URI]/api/data/v9.2/usersettingscollection(<service account's systemuserid>) HTTP/1.1
Authorization: Bearer <admin's own access token>
CallerObjectId: <service account's Microsoft Entra ID object ID>
Content-Type: application/json; charset=utf-8
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0

{
  "issendasallowed": true
}

Three things worth being precise about:

• The bearer token is the admin's, not the service account's — you authenticate as yourself. CallerObjectId is what makes Dataverse treat the call as if the service account did it themselves, which is what satisfies this being a self-service setting.
• CallerObjectId must be the service account's Entra object ID, found on their SystemUser.azureactivedirectoryobjectid column — not the admin's.
• The UserSettings table's primary key is the same GUID as the user's systemuserid. There's no separate "user settings ID" to look up; you address the record by the user's own ID.

The temporary-role step (1 and 3 above) still applies either way: the impersonated account needs enough privilege during the call to write its own UserSettings row, whether you're doing that call through Level Up or through this request directly.

Checklist for each environment

1. Confirm the user, queue and mailbox exist, and note the queue id. It differs per environment, so keep it in an environment variable.
2. Approve the mailbox. Set incoming to None and outgoing to Server-Side Sync. Test & Enable.
3. Temporarily add a role, impersonate, set issendasallowed = true, remove the role, and check the flag is still true.
4. Do the manual send test.
5. Run the flow, with a dry run first.

Things to watch

• The flag is per user and per environment, so repeat the steps everywhere.
• Treat production as its own change with its own approval.
• If you can't impersonate, the alternative is to ask your service desk to sign in once as that account and tick the box.
• If outgoing Test & Enable fails with an Exchange error, that's an Exchange admin issue, not Dataverse.
• If Exchange mailbox delegation is enabled, the sending account may also need Full Access or Send As on the Exchange mailbox.

Useful Microsoft Learn pages

• Send email on behalf of another user
• Fixing "You cannot send email as the selected user"
• Set personal options (Email tab)
• Approve mailboxes and Test & Enable
• Impersonate another user using the Web API
• User Settings (UserSettings) table/entity reference