Power Platform Archives

by : crim MS Power Automate, MS PowerApps

Missing support of appended text in Power Apps forms

Today while working with a Power Apps form I ran into an issue where I wanted to display the history of a SharePoint text field in my form.

In SharePoint you can modify your Mulitiple Lines of Text field, so that every time a change is made to the field, the change is appended to a history:

The result of the above configuration example will look as the following in the SharePoint list when making changes to the field:

This is what we would like to show in the PowerApps form

So, in my case I wanted to display this complete history in my PowerApps form from in a field called “Description” (in Danish “Beskrivelse”):

The field from which I would like to display all previous entries

To my surprise this was not really possible. I was only able to get the last entry to be displayed in my text field. But this did not resolve my requirement as I would like to display the complete history of appended text, as a kind of documentation of all log entries. Off course I could just look directly into the SharePoint list for this information, but what is the purpose of using Power Apps then?

What I did find was a solution based on MS Flow (see this article: https://www.c-sharpcorner.com/article/display-appended-comments-version-history-from-sharepoint-list-on-powerapps/)

This solution actually worked out, but having to rely on a Flow in order to resolve a very simple requirement, may be a bit too much. My concern is also that the execution time of the flow may have an impact on the user experience. Imagine what would happen if there is a delay of the flow completion? – which is very likely in Microsoft 365.

My conclusion is, that there is no really good solution for solving this problem until Microsoft provides a fully functional way of displaying the field history in PowerApps. I have seen several User Voice entries where people are asking for this feature. Let’s hope it will be there soon.

Who owns your Power Automate flow?

In my job I have already created several flows in MS Power Automate. Although I am familiar with the way flows are built and published, I am still frustrated about the way that flows are handled in Microsoft 365.

Back in the days (which is not so far ago) we created all our flows as SharePoint workflows or through products like Nintex, K2 etc.. Either you created your workflows directly in SharePoint (through SharePoint designer) or you paid for an additional product to administrate your workflows. Pretty simple model.

When Microsoft introduced MS Flow (now MS Power Automate), they introduced the product as service for all users: “Hey, it’s so simple to create flows, no coding, you can all create flows easily”. Yes, almost true. But Microsoft forgot to inform users about the way that flow really works – especially about the flow life cycle.

If you are used to create SharePoint flows in the traditional way. You know that publishing a workflow will apply to all users, and that the flow will continue to live even if the flow editor account is disabled or deleted (let’s say the user leaves the company). This though, is not always the case in MS Power Automate flows.

Let’s pick an example:

User A creates a flow in Power Automate for a SharePoint list to handle permissions for items (e.g. contracts) when they change value in a metadata “Status” field.

The workflow is created and published by user A, and it is changing permissions for the current item whenever any user is changing value in the “Status” field. Great! Happy camper.

… in the meantime, user A is leaving the company to pursue new challenges, so the IT dept. de-activates the account for user A and removes all his Office 365 assigned licenses. After a period they decide to delete the Azure AD account completely (OK, this may not happen in the real world, but it is seen though). Can you imagine what happens to the flow in this scenario? The flow is gone!

In the above scenario the consequences can be very damaging to the business process. All users with access to the solution where relying on the configuration of the flow that user A created. This is just a simple scenario for a simple workflow and it could have even bigger impact if the flow was very complicated and had several connectors (e.g. connections to Outlook/Exchange in context of user A, etc.).

The solution

Ok, so what can you actually do to get avoid the critical situation above. Well, it’s a matter of governance and discipline. Because, you can actually avoid flows created by users from disappearing out in the air (or cloud if you prefer) if you follow some basic rules:

Always add more than one owner to your Power Automate flows (see instructions below).
Train and educate your Power Automate flow users.
Create a strict governance/policy about the use of Power Automate flows.

Adding additional owners to a MS Flow

Adding additional owners to your personal Power Automate flow prevents the flow from disappearing when your user account is disabled/deleted. When adding additional owners to your personal flow it turns into a “Team” flow.

Example:

The following flow is already created as a personal flow:

… as you can see it appears as under the view “My flows”. Now, in order to change the flow settings you need to access the flow properties and add an additional owner (click on “Edit” in the “Owners” section)…

You can now start adding additional owners to your flow in order to ensure that ownership is no longer tied to your personal account…

Important! The result is that your flow is now turned into a “Team” flow and is no longer displayed in “My flows”. Instead it will appear in the “Teams flows” view…

What type of entities can I add as owners?

The great thing about this setting is that you can not only add users, but you can also add Office 365 groups (and even also SharePoint sites/lists) as owners (check out this link: https://docs.microsoft.com/en-us/business-applications-release-notes/april18/microsoft-flow/sharepoint-lists-libraries)…

The one important thing to note about connections

OK, so this flow ownership thing is great, but there is one thing that you need to be aware about. Even though you can add multiple owners to a flow, your flow may still be using connections in context of the original user.

Example:

Your flow is configured with a connection to SharePoint / Exchange or something similar (which is very likely)…

Whatever this connections is, the connection is by default tied to the user that created the flow. And that’s also the case when adding new owners to the flow. If you add a new owner to the flow, you will also see this message…

Adding multiple users does not really solve the issue with the flow being fully functional after the original user’s termination. Why? Because the connections in the flow are no longer valid! The flow simply cannot connect to something in context of a user that no longer exists.

I cannot think of a real solution for this. The only thing I can suggest is that you ensure that the connections you create in your flows always are tied to an active Microsoft 365 account. Using some kind of system account may be the solution. But, if you create solutions that require a lot of workflow runs, you may be hitting the account’s limit of free workflow runs. Make sure you are always aligned with Microsoft’s licensing model for flows: https://emea.flow.microsoft.com/en-us/pricing/

So why even add additional owners?

Adding multiple owners to your flow is still very much recommended. By adding multiple owners you ensure that your flow continues to live, even after the original author’s termination. But make sure your flow’s connections are always active, otherwise the flow may not run the in the expected behaviour.