You’re offline. This is a read only version of the page.
I am having an issue that I hope someone may be able to help with. My role involves building flows for people around my organisation. I have built a flow that sends an email from a shared mailbox. I know that you need to have access to the mailbox in order to send from it, so I built as much of the flow as I could, shared it with a member of the team I was building the flow for, and then got them to do the last few bits over a screenshare - such as adding the shared mailbox into the 'To' field of the step that sends the email. This resulted in an error, as I do not have access to send from that mailbox, even though she was the one to change it (I have checked and she definitely has access herself).
The problem is that I do this for the entire organisation - I do not want or need access to other people's mailboxes ( the teams also so not want me to have access to their mailboxes). All I want to do is build the flow for them and make sure it works sending an email from their mailbox. I also don't to use my own email address as this a/ gives the impression I sent it, and b/ results in people emailing me for help with their requests, which have nothing to do with me.
I know Microsoft also do not like us using service accounts. So how do I get around this?
Ben
There is no way around this. Whomever is the owner of the flow needs permission to do what the action needs to run. That is part of the security if you think about. If there were a way around this, then what security would there be to prevent people sending e-mails from a shared mailbox if they don't have permission? If they don't want to give you permissions, then someone who has permission to send from the shared mailbox will need to be the owner of the flow.
If you put the workflow in a solution, you could add someone who has permission to send from the mailbox as an owner of the flow. Then have them update the connection reference for the send from a shared mailbox to use a connection reference generated from their account.
@BenHolloway This has been a common question during the almost 6 years I've been building flows and apps for my company of 60,000 worldwide staff. I always make sure I have full send privileges on the shared mailbox. But I have so many that I neither have the time nor inclination to go into the mailbox unless someone alerts me to a n issue that I need to test. There is no way round that unless you are able to have a Power App in which case a button to trigger a flow (which needs to be send an email v2) will run in the context of the person who clicked the button, so the email will come from them and not from you.
Rob
Los Gallardos
Principal Consultant, SharePoint, Forms and Power Platform, WSP Global (and classic 1967 Morris Traveller driver)
Thank you Rob - I appreciate your answer. I assume though that I am not the only person in my position of having to build flows for people around an organisation. So do you know how other people in my position do this? How do ICT teams, for example, build flows for teams around an organisation without using service accounts and avoiding having to get access to mailboxes. I work for a organisation that has high security and information assurance protocols - for very good security reasons I do NOT want access to other teams' mailboxes, and they do not want me to have access either. Is there any other way around this?
@BenHolloway the send email actions in Power Automate work in the context of your connection as the creator of the flow, so even though your colleague did some of the flow, that doesn't get over the fact that it's using your connection for the send email. If you build flows for other people you will need to have full send privileges on the shared mailbox.
"All I want to do is build the flow for them and make sure it works sending an email from their mailbox."
That's not possible.
Rob
Los Gallardos
Principal Consultant, SharePoint, Forms and Power Platform, WSP Global (and classic 1967 Morris Traveller driver)
Share
Report
4
All responses (
Answers (
