Power Platform Governance: risks of maker collaboration via comments

Recently Microsoft announced the general availability of the comments feature in Power Apps and Power Automate. What this allows is for multiple different makers to collaborate on objects like canvas apps or cloud flows via associating comments to individual items inside them. It is very similar to the Office commenting experience, meaning those users who have previously collaborated on documents this way might quickly start leveraging it also for apps and flows.

One key aspect of what makes comments more than just text boxes is the ability to at-mention other users and tag them into the comments thread for both visibility and input. For example, when our user “FF Admin” is building a Power Automate cloud flow and wants to get the attention of another user, “FF App Maker”, it’s very quick to just mention them in a new comment associated with a particular step in the flow:

Some people might be tempted to go all-in with this commenting approach and use it as a lightweight change log for keeping the team informed on the recent changes. After all, there isn’t really any built-in functionality for this kind of release notes in the Power Platform products today. So, instead of deploying pro-dev tools like Azure DevOps and putting in the effort for connecting different systems to together, why not just do it all here?

Collaboration and the required access rights

To achieve a net positive impact to the business via leveraging low-code application platforms like Power Platform, you really should have a governance model in place. Yes, tools like Power Automate are a very quick way to build automations and integrations that would have earlier required custom code or expensive enterprise software suites. Yet when we go beyond the personal productivity scenarios and start automating enterprise wide processes, you shouldn’t treat things like cloud flows as “just a document that you share with collaborators”.

Unlike documents made of words, cloud flows actually perform actions on behalf of users. This makes managing their security a critical factor from a governance perspective. Who has access to the configuration, what identities are used in the connections to other systems, how do we protect the automations from unwanted changes. When new features and possibilities become available through product updates from Microsoft, the impact to these security factors needs to be evaluated.

The important part to pay attention to, and the key point of this blog post, is the following functionality that’s just briefly mentioned in Microsoft’s commenting feature announcement blog post: “If the flow has not been previously shared with a colleague, the user will be prompted with a ‘Share and notify’ option that will share the flow and send an email notification to the colleague.”

After mentioning a new user for the first time inside our cloud flow editor experience, the “grant access” dialog will be presented. “These recipients don’t have access to this flow. They will not be able to see or reply to your mention unless you give them access.” Well, that sounds innocent enough! Of course we want to give them visibility into what we’re building here, so let’s click the “share and notify” button:

Let’s pause for a moment: what did we just do here? Was the new user given access to join in on the comments discussion? Were they given visibility to the flow steps which the comments are related to? Yes and yes – but they also gained more rights than we probably intended to grant.

We must keep in mind that there is no “collaborator” role available in the security model of Power Automate cloud flows. We don’t even have the “editor” level that Power Apps canvas apps support. There are only owners when it comes to flow. By clicking the share button after being prompted by the comments feature, we actually made the new user a co-owner of our flow:

The user to whom the flow was shared, FF App Maker, is now indeed one of the official owners of the flow. Looking at the ownership information from the Power Automate maker portal, we’ll see 2 owners for the flow. The last added user is even listed here first:

This screen has important guidance on the left side – something which the new Comments feature and its sharing dialog unfortunately doesn’t mention at all:

  • Owners: “Adding an owner gives them full control of this flow, so make sure you only share with people you trust. They’ll be able to add or remove other users as owners, access the run history, and can update, edit or delete this flow.”
  • Embedded connections: “Everyone listed as an owner will have access to all these connections and will only be able to use them in this flow.”

Okay, so the last part about only being able to use the connections inside this one flow does provide some relief to our concerns. However, it doesn’t mean we wouldn’t have unintentionally opened up a security loophole for our collaborators.

As the new co-owner of the flow, FF App Maker now has the ability to edit all the steps in the flow. The user is also able to add new actions into the flow, using the credentials that the original flow creator (FF Admin) had entered while building it. This means that we as the FF App Maker are completely free to perform any actions against Azure AD, such as adding a user to a security group:

What else would the Azure AD connector provide us? Looking at the documentation for available Azure AD actions, we could create new users and groups, read all the details, update user info, assign managers, modify group membership. That is a lot of power.

Even if the collaborator wouldn’t have any malicious intents, there is still a real risk that they migh modify the flow in ways that cause problems. Perhaps they’re not aware of what the allowed scenarios for Azure AD data modification within the organization are. Maybe they’ll accidentally override some IT security procedures and cut corners. After all, low-code solutions could often deliver business users the results that have previously been too slow and time consuming when using the official channels provided for IT services.

Can we at least see what changes the collaborators have performed on the flow logic? Sorry, today there’s no audit history for flow metadata available. Okay, can we at least restore an earlier version of the flow definition if we notice unintentional updates to it? You wish! There is no still no built-in version history available for cloud flows, like there is for canvas apps.

Luckily the “share and notify” option in Flow Designer is limited to only non-solution aware flows. However, for any organization that seeks to use comments as a form of collaboration rather than just private notes, the number of co-owners that will get added to cloud flows is likely to increase as a result.


It is quite common that several different makers will need to work on common elements in the low-code application platform when building solutions. Introducing the in-product comments feature across the main elements (canvas apps, model-driven apps, cloud flows) can surely help those teams that have established practices on how and where they develop their solutions.

Before you start to just at-mention people who might need to comment on the functionality of apps and flows, think through the scenario of what granting them editing access to what’s effectively the “source code” of your low-code solutions will have on your system security and maintainability. Is everyone you’ll mention in the comments a qualified maker that knows what they should & shouldn’t do in the Studio experiences for apps and flows?

Also keep in mind the ALM considerations for entering detailed release notes about the configuration changes into the comments in apps and flows. They are only stored in the Comment table of the current environment’s Dataverse database. If you move your apps and flows from development to test to production environments, don’t expect the comments to be visible there (without manual export/import).

Interested in reading our latest Power Platform blog posts?

You’re welcome to subscribe to our email newsletter: Forward Forever News. Max 1 email per month, with a curated list of latest insights and articles on Power Apps, Power Automate, Power BI.


  1. Maria
    2023-05-02 at 11:12

    Maybe worth adding these wished to uservoice of PP? “Can we see what changes the collaborators have performed on the flow logic? / audit history for flow metadata and “can we restore an earlier version of the flow definition if we notice unintentional updates to it?”

    1. Jukka Niiranen
      2023-05-02 at 13:34

      What’s this “UserVoice” you’re referring to? Some feedback platform that used to exist before Power Pages community template for idea management? 😉

      There are indeed quite a few existing requests made for version history management of Power Automate cloud flows. The capability has been on the product team roadmap for quite some time and now the 2023 Wave 2 is promising a public preview of “use versioning for solution cloud flows” coming in June.

      The Power Automate Ideas site has an idea collection item called “drafts and versioning for flows” that talks about a preview in July 2023. Being a topic with a whopping 1,887 votes and 129 comments over the past 5+ years it is certainly something the Makers with experience on working with Power Automate have been eagerly waiting for. At the same time, if you’re a new maker or an IT person in charge of taking ownership of the administration and governance of Power Platform, this gap in the product features may not be very obvious to you.

      Comments now went GA, perhaps the version history and reverting unintentional changes made by the collaborators will make it in the next ~year or so. In the meantime, being very careful about what you touch whenever you open the Power Automate cloud flow designer is certainly advisable.

Leave a Reply