I spent an entire afternoon on this one. If you've configured a password reset flow in Power Pages and your emails are sitting in Pending Send forever, never actually going out, this post is for you.
The surface-level problem looks like an email configuration issue. You've got Exchange Online set up, server-side sync enabled, and the workflow looks fine in Dynamics. But the emails never send. I went down a long road of mailbox settings, queue configurations, and Send on Behalf permissions before finding the real fix. Spoiler: Power Automate is the answer, and once I switched to it the whole thing worked in minutes.
Let me walk you through what's actually happening and how to fix it properly.
In this post
Why the Emails Get Stuck
When a user hits the password reset button on your Power Pages site, a workflow called Send Password Reset To Contact fires. That workflow creates an Email record in Dataverse with a status of Pending Send. From there, Dataverse relies on server-side sync to pick up that record and actually deliver it through Exchange.
The problem is the workflow runs under the PPMI-powerpages application user. That's a non-interactive system user that Power Pages uses internally. It doesn't have a real Exchange mailbox, it can't be added to Exchange mailbox delegation, and it has no path to actually send email through server-side sync.
So the email record gets created correctly, sits in Pending Send, and nothing ever picks it up. It's not a sync issue, it's not a mailbox configuration issue. The app user simply cannot send email.
Finding the Real Error
If you try to change the From field in the workflow to a real mailbox or queue, you'll start getting errors when users hit the password reset button on the site. To find the actual error message, go to Advanced Settings → Processes, open the Send Password Reset To Contact workflow, and click Process Sessions in the left nav.
When I changed the From to a queue, the process session showed this:
System.ServiceModel.FaultException: The user 8c2de4be-d854-f111-bec7-6045bd083d1e selected in the From field does not have the option enabled to allow other users to send the email on their behalf.
After fixing the queue setup, a second error showed up:
System.ServiceModel.FaultException: Could not find email address for recipient of type 'Queue' with ID '68e8c374-6e5b-f111-bec7-000d3a34bbe1'
That one was because the Queue record in Dataverse had no email address on it. Fixed that, and the send-on-behalf error came right back for the same fundamental reason: the PPMI-powerpages user is always the one invoking the action at runtime, and you cannot grant it Exchange permissions.
Why the Native Workflow Can't Fix It
The Send Password Reset To Contact process is a custom Action, not a standard workflow. That means it doesn't have a Run As option you can change. The Owner field on the Administration tab shows your account, but the invoker at runtime is always the app user. No matter what you put in the From field, as long as PPMI-powerpages is executing the action it will hit the send-on-behalf wall.
You could try granting the app user Exchange permissions, but that email address is a system-generated address that doesn't exist as a real Azure AD user. Exchange won't let you add it to mailbox delegation. I tried.
The native path is a dead end. This is the same fundamental constraint you run into any time you're doing serious CRM automations with system users — they're great at creating records but terrible at anything that touches external services.
The Fix: Power Automate
The solution is to bypass Dataverse's email sending entirely and use Power Automate to watch for new email records and deliver them through Office 365 Outlook. Power Automate runs as your licensed user account, which has a real mailbox and can be granted Send on Behalf permissions on a shared mailbox. No app user involved.
1. Create a shared mailbox in Microsoft 365
Go to Microsoft 365 Admin Center → Exchange → Recipients → Shared Mailboxes and create a no-reply address like noreply@yourdomain.com. This will be the From address on your password reset emails. Then go to Mailbox Delegation → Send on Behalf and add your licensed user account.
2. Build the Power Automate flow
Go to make.powerautomate.com and create a new Automated Cloud Flow. Set the trigger to When a row is added, modified or deleted using the Dataverse connector with these settings:
- Change type: Added
- Table name: Email Messages
- Scope: Organization
3. Add a Condition to filter for password reset emails
Add a Condition step after the trigger:
- Left side: Subject (dynamic content from the trigger)
- Middle: contains
- Right side:
Password Reset
This prevents the flow from firing on every email record in your system.
4. Add Send an email (V2) in the If yes branch
Inside the If yes branch, add a new step and search for Send an email (V2) using the Office 365 Outlook connector:
- To: dynamic content → To Recipients
- Subject: your subject line or the dynamic Subject field
- Body: click the
</>code view button in the body toolbar, then insert dynamic content → Description - From (Send as): under Advanced parameters, enter your shared mailbox address
The V2 action renders HTML automatically when you insert the Description in code view mode. No extra toggle needed.
5. Save and test
Save the flow, then trigger a password reset on your Power Pages site. The flow should fire within seconds and the email lands in the user's inbox with the properly formatted reset link.
Critical Caveat: Don't Run This Flow as Yourself Without a Shared Mailbox
If you skip the shared mailbox setup and let the flow send from your personal licensed account, every password reset email that goes out will show your personal email address as the sender. That means your real email gets exposed to every user who resets their password on your site, and anyone they forward that email to. Don't do this.
Always set up a dedicated shared mailbox like noreply@yourdomain.com and use the From (Send as) field in the Send an email action to send from that address. Your account handles the authentication behind the scenes, but the address the recipient sees is the shared mailbox. Clean, professional, and your personal address stays private.
The Send on Behalf delegation in Exchange is what makes this work. Without it, Power Automate will throw an error when you try to send from an address other than your own. Add your account to the shared mailbox delegation first, then set the From field in the flow.
Why This Happens and Why It's Not Obvious
Microsoft has been deprioritizing local authentication in Power Pages for a while now, pushing everyone toward external identity providers like Azure AD and Microsoft accounts. The result is that the local login and password reset flow works at the UI level but the underlying email delivery mechanism was never wired up cleanly for the app user model. It's a gap that shows up in obscure support threads but nowhere in the setup documentation.
Power Automate is a better approach anyway. You get full visibility into flow run history, easy error handling, and you're not dependent on server-side sync behaving correctly. If something breaks you can see exactly which run failed and why, rather than staring at email records stuck in Pending Send with no useful error message anywhere in sight.
This same pattern comes up a lot when you're building automation on top of platforms where system users have limited external service access. I've run into similar walls automating faxes in healthcare workflows and when building out AI agent integrations that need to send communications on behalf of the system. The answer is almost always the same: get the licensed user involved and let them be the sender.
If you're building on Power Pages and need local authentication to work, save yourself the afternoon and go straight to Power Automate for the email delivery piece.
