I have been testing results locally in my development environment with the "Start and wait for approval" connector so that Microsoft Form submitters and approvers can see each other's information through Outlook 365. That part has been great so far.
But now that my flow is ready to be used at an organization level, how can "I" run my flows, and make it appear that all the From's: and Created bys: and Requested bys: in Outlook 365, are not coming from me, (littleODeveloper@company.com), but instead are coming from a higher level...(i.e.) hr@company.com? I obviously don't have access to the human resources email account within my organization, and I am the only employer who knows how to run flows. Regardless, these flows are for the organization level, so I need a way to find settings, or connectors that will allow these flows to appear as they come from top level email accounts of the organization, not my own.
My two primary connectors in my project:
Here is one example, whenever I run the Outlook 365 Send an email v2 connector, its fine it says it comes from me when I am doing local testing/prepping/developing. But as soon as this flow package is ready to be used in a company setting, it shouldn't be coming from me. It should be coming from a company level account.
How can I capitalize on this? How has IT developers on this thread found a way around this issue?
Solved! Go to Solution.
Hello @kensley
Best practice would be to have service accounts.
These accounts should be only used for automation and flow. If you use azure, the credentials could be stored in key vault.
for example:
you could have a service account email as:
Automate.Flow@<yourOrg.com>
Proud to be a Flownaut!
Hello @kensley
Best practice would be to have service accounts.
These accounts should be only used for automation and flow. If you use azure, the credentials could be stored in key vault.
for example:
you could have a service account email as:
Automate.Flow@<yourOrg.com>
Proud to be a Flownaut!
Hi @Jcook ,
how would you go about setting this up? In my organisation we need to create workflows that run run against SharePoint items, and want it’s imperative that they run every time.
We can create a service account, but our concern is password expiration. We have a very strong password policy which requires accounts to renew password more often than your average organisation. This does not exclude a potential service account for this scenario; therefore we’ll need to be on top of that workflow.. refreshing the connection..? whenever the password expires. We want to avoid that at all costs
I’m now wondering is adding Azure KeyVault in the mix could help build a case to put forward to our security department (but I’ll need to know how to make it happen first l!).
Or if there’s a way to use something like Azure managed identities so we don’t want to worry about credentials at all (I read somewhere Logic Apps a better suited for our scenario, but the authentication issue remains)
Any information you can provide will he greatly appreciated
Hello @DresP
In my org, we use plenty of Service accounts, and the password policy set on those accounts does require a change every month. What I have noticed is, all integrations or flows that have this connection are not affected unless you are redeploying them, or making a new connection.
** This is what I have encountered, this could be different for you or someone else **
Proud to be a Flownaut!
User | Count |
---|---|
27 | |
16 | |
15 | |
10 | |
10 |
User | Count |
---|---|
45 | |
29 | |
28 | |
24 | |
23 |