cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
kensley
Resolver I
Resolver I

How to run Power Automate connectors as a company level account?

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.comI 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:

 

  • "Start and wait for approval"
  • "Outlook 365 Send an email v2"

 

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?

1 ACCEPTED SOLUTION

Accepted Solutions
Jcook
MVP

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>


Did I answer your question? Mark my post as a solution!

If you like my post please hit the Thumbs Up


Proud to be a Flownaut!


Check out my blog for Power Automate tips,
tricks, and guides
FlowAltDelete





View solution in original post

4 REPLIES 4
Jcook
MVP

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>


Did I answer your question? Mark my post as a solution!

If you like my post please hit the Thumbs Up


Proud to be a Flownaut!


Check out my blog for Power Automate tips,
tricks, and guides
FlowAltDelete





@Jcook, thanks for helping me see how this issue is being solved today through our Microsoft applications.

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 **


Did I answer your question? Mark my post as a solution!

If you like my post please hit the Thumbs Up


Proud to be a Flownaut!


Check out my blog for Power Automate tips,
tricks, and guides
FlowAltDelete





Helpful resources

Announcements
Power Automate News & Announcements

Power Automate News & Announcements

Keep up to date with current events and community announcements in the Power Automate community.

Community Calls Conversations

Community Calls Conversations

A great place where you can stay up to date with community calls and interact with the speakers.

Power Automate Community Blog

Power Automate Community Blog

Check out the latest Community Blog from the community!

Users online (4,040)