I have a flow that needs to send a few different email notifications to based on the outcome of the flow.
Because the flow runs a few hundred times a day, I had to switch from using flow's native send email action to an Outlook action, but I don't want it using my personal email address to send those so I had a service account created to handle that.
My company's service accounts follow a specific naming convention but I wanted the email address showing up to the users receiving these notifications to see a "No Reply" email address, so I had the service account set up with an email alias using a No Reply format.
I set up a new Office 365 Outlook connection using the service account was able to switch my flow's email actions over to that account successfully. I then tried to use the Reply To option in the action's advanced options to specify that the email should use the service account's email alias, which I've confirmed is set up in Exchange properly.
However, the flow seems to just ignore that setting and still sends the email using its default email address.
Of note - when I first added the email address to the Reply To field in the Outlook Send an email (v2) actions, it didn't reformat from simple text to a validated value. So I re-entered the email address a second time and this time I waited a bit before saving, and the field eventually displayed as a validated value so I re-saved and tested again. That didn't change the result, though - emails are still being sent using the service account's default email address and not the alias I'm telling it to use as its Reply To value.
I can't find much on this topic in these forums or elsewhere, so I'm hoping someone here has run into this scenario and can tell me what I'm missing. Thanks!
I need to test, but I suspect that the email you have used is resolved to the "base" email address by the Outlook connector and that there is no way around this....
It feels like that's what is happening, but I can't find anything on how the Outlook connector handles the Reply To field.
The Reply To field acts like it has validation capabilities - it presents a "Suggested People" list in the dropdown pop-up when I click into the field and it does perform an auto-lookup as I type in any potential email address to look for matches in AD. It doesn't find the alias I'm entering since that address is not a valid AD user, but it does convert the address to a removable value so it does seem to be validating it somehow.
I tried putting in an invalid email address to see what happens, and it won't accept any random email addresses outside of my company's domain. I can type those in but if I click out of the action and back into it, that invalid email address is no longer there.
I doubt this will work, but it is worth a try. Use a Compose action and enter the email address. Reference the compose action in the Reply to area and test.
I added a Compose action to store the No Reply email address I want it to use, then set the Reply To value to the output of that Compose.
That flow change saved with no errors returned, but when I retested the action using the new setting, it didn't generate an email message at all - even though the flow history is showing that the send email action successfully completed with no errors.
UPDATE: The missing email was a problem on my end, my internet hiccupped and my Outlook went offline so I wasn't seeing the notification I expected to see. The email did get generated by the flow, but still using the default service account email address and not the No Reply alias I want it to use.
I'm checking with my Azure/Exchange admins to see if there's even an option to change the default email address associated to the account to something other than the account's name, but I'm doubtful that will be an option.
Check out the new Process Advisor community forum board!
Check out new user group experience and if you are a leader please create your group
On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks