Sharing Flows as Owners and Run Only Users
    • Dark
    • PDF

    Sharing Flows as Owners and Run Only Users

    • Dark
    • PDF

    Article summary

    In addition, sharing helps mitigate off-boarding issues when someone decides to leave an organization. If a flow is already shared with a teammate, then the impact of one of the owners leaving is reduced.

    There are two different modes of sharing that exist within Microsoft Flow: Owners and Run only users.


    Sharing a flow as an Owner provides the new owner with access to:
    ● Modify the flow
    ● View Run History
    ● Run the flow
    There are benefits and risks associated with providing this level of access. From a benefits perspective, when a user is a co-owner, they can make changes or troubleshoot the flow. This is a great way to scale its use and maintenance of the flow.

    However, if a co-owner had malicious intents, they can modify the flow and re-use existing connections to modify the intent of the flow. For example, consider a situation where the flow has a SharePoint trigger that connects to a SharePoint list and retrieves new records that have been added to the list. The flow then sends out an email to a distribution list using a connection that was created by the original owner and sends email on their behalf. The original maker goes on vacation and a malicious co-owner modifies the flow by removing the SharePoint trigger and replacing it with an Office 365 Email trigger. The malicious co-owner then scans the original maker’s inbox, essentially reading their mail.

    To mitigate this scenario, Microsoft sends out emails whenever someone changes a shared flow. However, since this malicious co-owner has access to user’s inbox, using Flow, they technically can clean-up after themselves.

    Run only users

    Sharing a flow with Run only users is a great way to share your flow logic, without exposing some of the risks that we discussed in the previous section. When sharing a flow using this mode, users can run your flow, but do not have access to modify it or browse Run History. The downside of this mode is that it only applies to manual triggers such as Flow, SharePoint, Dynamics 365 and OneDrive for Business buttons. The reason for this is that the flow will run in the user’s context so we have an authenticated session. By allowing the flow to run in the user’s context, it also gives us the opportunity to leverage a user’s connection or a static connection that was created by flow owner.

    When you share a flow using Run only user, the flow owner can determine how connections will be used. If the flow owner specifies that connections should be Provided by run-only user, that means a user will have to create a connection before they can use the flow and when they run the flow they will use that connection. This is particularly beneficial when you want emails to be sent on behalf of the user that clicked the button.


    Sharing is a very important concept in Microsoft Flow, but it is important to understand the different modes that exist to ensure you are not increasing risk to your organization and also providing a better experience by taking advantage of using a user’s context and their connection when sending out email notifications

    Was this article helpful?