A Complete Guide for Migration to Power Platform: Pre-Development Analysis – Part 1

After having a clear understanding of what the tool can offer, how it can be leveraged in your projects should be well planned. If the application is going to be created from a new requirement, we can focus only on the Power Platform by analyzing the use cases of the requirement and a feasibility study should suffice for common scenarios like approval, functions, references, CRUD operations, integrations, performance, limitations has to be taken care.

Following are some of the Power Platform limitations which one might face in the development phase, hence it should be addressed in the pre-development analysis.

Power Platform Limitations

One of the common limitations is, PowerAutomate flows will live only for 30 days, most of the flows will get completed in a maximum of 5 minutes except if the following actions like Do Until, Approval, Pause until were used. This must be addressed while implementing solutions and will apply to workflow run history also.

Power Platform solution architects should be well versed in the cost perspective to give a better solution.

Flow Infinite Loop

This is a common limitation in most of the workflows especially when it is tied with SharePoint. When the workflow updates the current item and the workflow trigger is on item update, a design issue will be thrown. If the list has a customized form it can be managed with a flag column otherwise it should be handled within the flow.

Threshold Limitation

One who is well-versed with SharePoint will be familiar with this issue, SharePoint has a threshold limitation of having a maximum of 12 lookups in a view. We can add more than that to the list, but it will throw integration errors in PowerApps and flow behavior will be a bit different. It could be managed by mapping the flow actions and triggers to different views with limited lookup columns.

Default Impersonation

Power Automate by default will run in the flow owner instance, on an update or create item action in the flow, owner name gets updated in the metadata fields instead of the actual user name who initiates the trigger.

Email From Address

Email actions in Power Automate will send mail from the owner instance, and the email is sent from the owner mailbox. The mail receiver will be confused a bit in such a scenario when it is not configured with their site or app name.

Library Attachments

There is no out-of-the-box control to upload files to a SharePoint library, we have to do it in a roundabout way.

Check user in SharePoint group

Power Automate has no OOTB function to check whether the user is a part of a particular SharePoint group.

Print Option

This is one thing on which Power Apps really need to focus on, Even though they have a Print() function it is not working in SharePoint Customize form.  For this problem, an HTML form has to be created to achieve this functionality.

This is part 1 of the Predevelopment analysis post, Please do follow up on the next post for the analysis based on the legacy systems.

Please leave your valuable comments and suggestions, Happy Building 🙂