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

Now if you have followed the previous posts you might have quite an idea of how to step into the development process. While development is a small part of the software life cycle model it is merely an output of the analysis made from the existing system or new requirement. 

Most of the development-related practices will relate SharePoint with PowerApps as the whole series discusses Power Platform remediation with SharePoint.

To give a glimpse on what level analysis has to be done in the existing system which will help in the development process as follows,

InfoPath forms

• Data connections should be analyzed for the count of lists that are connected to and how it is used; can be checked in other areas

• “Form Load” rules which need to be executed when a new, edit or view form is loaded. Mostly querying the data connection with filter condition, setting field value based on condition, disabling or hiding controls based on conditions will be listed here.
• “Set field value” is a tricky action. If it is used before query action and the value is set into the query section it will act as a filter value or if it is used in the data section it will set the value to the control.

• Rules can be found in the section or control to disable or hide them based on conditions.

• If a rule is tied to control, it will work on the change event of the control. So, those set of rules will fire whenever a value is changed in that control.

• Button click rules, mostly it will be used to call the main data connection for saving the data and subsequent behavior should be noted. Some forms will not close, it will reset and wait for the new entry.

• Duplicate controls in Infopath are common, the same control will be referred to in multiple places and if the value changed in one control it will be reflected in the other control.

• Required field and the logical error messages should be noted.

SharePoint Designer Workflows

• Approval workflows should be analyzed thoroughly like delegation, escalation, reminder configurations are configured and the Reusable approval workflow will be different from the normal approval workflows. In the reusable approval workflow approvers can be configured while triggering the workflow.

• Impersonation step should be noted

• Check for Item level permission, as it is directly not available in Power Automate we have to implement a roundabout solution.
• Set field action will behave differently in SharePoint 2010 and SharePoint 2013 designer workflows. In SP 2010 the update triggers the workflow once, but in 2013 it will not consider it as an update.

• Finally with the implementation style, we should not design flows as-is from the designer because an amateur might have done the development or things might be implemented based on the designer restrictions. So it is always recommended to understand the business and should be implemented based on Power Automate standards.

Note: All the analysis notes can be tracked into a document starting from the control or action level. Later, it should be mapped with its equivalent PowerApps or Power Automate control to maintain the integrity of the development process.

Please leave your valuable comments and suggestions, Happy Building 🙂