Rewriting InfoPath and SharePoint Designer Workflow to PowerApps and Power Automate.

Microsoft has recently announced about ending Support for Designers workflows, you can read about this announcement at this link. There is a very good article from Joel Oleson where he has explained about timelines etc. Because of this many organizations which are heavily invested in Designer workflows have now huge tasks of rewriting workflows in PowerAutomate. Though Infopath forms are still supported, but as part of a migration strategy, architects are choosing to also move away from Infopath to Powerapps wherever necessary.

In this article, I will be sharing some learnings and things we have to keep in mind when rewriting Infopath and SharePoint designer’s workflow to PowerApps and PowerAutomate. I will be adding new items/learning and notes to keep the article up to date. If you think and have experienced something which is not listed here, feel free to add in comment.

This article might help you as a technical team to plan your redesigning and also for a business analyst to inform business users on how end-users experience might change.

Log History List of Workflow

  • Being a Designer workflow developer myself, I know all workflows will have heavy usage of action “Log to History List” and this was our only way to debug the issue.
  • This action item is not available in Power Automate, but you can see flow run history and its details about every action in the Power Automate dashboard itself. Power Automate flow run history will show you the input and output of each action/condition.
  • So ideally Power Automate provides a better way to debug or track the issue, but if you are keen to keep your own history you can do so by logging the output in your custom history list.

Workflow Run History of SharePoint List/Library Item

  • One of the major drawbacks of Power Automate is that you can’t easily find the Flows run history for a particular list item.  This was very handy in the Designer workflow.
  • Many have requested this feature as User Voice, you can vote here for the product team to consider this feature.
  • Until then you will have to use some workaround, one of them which I found is at this link.

Sharing PowerAutomate/PowerApps with Users

  • We don’t need to provide separate permissions or share Infopath Form or SharePoint Designer workflow with the users, this granted automatically who has access to SharePoint.
  • This is not the case with PowerAutomate and PowerApps, You will have to separately Share PowerAutomate(manually triggered) and PowerApps with users who are part of the application or workflow and need to perform some actions.
  • PowerAutomate flow which you need the user to trigger manually from the SharePoint list command bar won’t show for them until that PowerAutomate is not shared with them.
  • So just make sure you are sharing your Powerapps and PowerAutomate accordingly once you move it to production enviorment.

StandAlone Powerapps Or Customize Form with Powerapps for SharePoint List

  • It is very important to analyze and find out, how the user is interacting with Infopath form and from how many places.
  • If your current setup is using OOTB views spread across multiple pages from where users can open List form, we should go with Customize Form options.
  • Workaround to open Power apps from SharePoint OOTB view  – Now you can always use Modern column formatting to add a link to OOTB views and providing a button to your stand-alone Powerapps and passing current Items ID in the query string.
  • The main issue with the Standalone app is how to related List Item with your Power Apps so that it opens different screens like view/edit or new form. This can be handled by using a query string parameter to Powerapps and controlling which screen to open based on the Parameter value to be passed and also prepopulate values in form based on ItemID.

If you are interested in knowing about this in detail below are a couple of links that are very helpful.

Power Apps Standalone App versus Customized List Form

Opening PowerApp using SharePoint Column Formatting By April Dunman

Infopath Forms Library to Powerapps with  Unpublished Field and Repetitive Sections.

  • Infopath forms library has a special feature where field value/data is stored in XML. Now when you want to create Powerapps for this kind of library, you will have to convert Form library to SharePoint List.
  • With forms library, you can choose to publish only a few fields to SharePoint. if you have not published certain fields/columns, these fields are stored in XML and are not available in SharePoint list settings or to display in OOTB view.
  • Now to convert this Infopath Form library to Powerapps, we will first need to publish all the fields to SharePoint list on the source form library so that these fields are available for you to read from your custom script or migration tool and in PowerAutomate flow. One positive note here is that, if you choose to publish these fields the values are automatically copied from XML to SharePoint list columns so you don’t need to worry about data.
  • I have come across a certain migration strategy wherein, we choose to keep the older form library as it is for older data(archive) and then redesigning by creating a New SharePoint list and customize it Powerapps and rewrite PowerAutomate flow to refer to new List.
  • If your form library has repetitive sections, the field/columns within repetitive sections are store in XML only and cannot be published to SharePoint List. In this case, our only option is to Create a List for the main Form library and create a child list for each repetitive section to maintain one to many relationships. I would love to hear if you have thought or any other option.

Handling Hyperlink Column type with Powerapps List Form

  • Hyperlink field is one of the complex types which has 2 main properties a. Link Display Text and b. URL.
  • Now with Infopath form, if your column type is a hyperlink, it knows the type and renders it as a formatted hyperlink field in the view form and also provides the nice option in the popup to edit both Display text and URL.
  • In Powerapps using List form and providing SharePoint list as a data source, Hyperlink type of fields only allows you to edit the URL of the field. We will have to write custom logic to render this field as clickable in form. We will have to also create a new Column to allow users to edit display text and use these 2 columns to make the link clickable. You can find some discussion around this at the below links

https://powerusers.microsoft.com/t5/Building-Power-Apps/SharePoint-List-form-Hyperlink-Column/td-p/235131

https://powerusers.microsoft.com/t5/Power-Apps-Ideas/Description-Field-from-Hyperlink-Column-in-Sharepoint/idi-p/303521

https://powerusers.microsoft.com/t5/Building-Power-Apps/Sharepoint-List-Hyperlink-using-PowerApps-form/td-p/391800

There is a step by step tutorial video by Dhruvin Shah on the same topic, you can refer to it here.

Task List/Approval  with Flow

  • With Designer workflow, there are options to associate a Task list with every workflow and handy Action “Assign a task” which will create a task in the list, assign it to as user, and also send a notification, There was also an option to wait for the execution of workflow until the task his completed by the user. This feature was widely used for approval scenarios.
  • Powerautomate does not have similar action associated but there are different ways to achieve this. Below are some of them which I can think of.
    • Use flow’s “Start and Wait for approval”. This is the perfect replacement for Assign task action in the designer workflow if you do not have any Page/place where you are displaying all pending tasks of the user(My pending tasks view) within SharePoint.
    • If we use “Start and Wait for approval”, the user has to options to approve/reject tasks.
      • Option 1 – Directly from Outlook email, this is way faster as approver can directly complete task from outlook.
      • Option 2 – Flow dashboard. (refer screenshot below)

    • “Start and Wait or approval” might work in a certain situation but below are some of the caveats which you should consider.
      • This won’t work when you want approvers to edit certain fields while they are completing tasks.
      • It is not possible to provide a single consolidate view to all the approvers where they can see all pending tasks, with option 2 they can use Flow dashboard but user experience will change how they used to view their pending actions items which are outside of SharePoint Site url.
      • We might have created a certain View using OOTB or using the content editor web part which displays other information along with pending tasks like actual item detail for them to quick reference.
  • In certain situations, you might want to get rid of the Task List and task forms and create your approval/task solution by creating custom list columns handling the business process. After all, you are rewriting with new technology so better to get rid of old stuff might be the best approach.

Designer Workflow actions/steps with PowerAutomate

Migration/Rewriting the existing functionality/app to new technology is always challenging, there is no straight forward way and you will always find alternate solutions. Many of them might be better but sometimes we as a developer and/or the business users have to adapt. After all

We are nothing if not adaptable

Happy Coding..!!!

Please share your feedback/findings in the comment section..!

(Visited 2,272 times, 1 visits today)