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

This is a continuation post on the Analysis and Development series, have a look at Part -1 of this post for a better understanding.

After properly analyzing the existing system, we might be in a good position to start the development. Let’s see the list of things that should be followed while developing,

• If the development is started from the “SharePoint customize” form,
  • The list name from the production environment and development environment should be the same because after importing it to production if the list name is different, Datasource name should be reconfigured to the production list name wherever it is mentioned.

• Use variables for the static contents like URL, values, etc and place them on top of the workflow. So, once deployed to production it is very easy to change the variable values to make them point to the production site. JSON values declared in compose action can be called using expression. For instance outputs(‘Set_Variables’)[‘URL’]

• If it is a direct canvas app, the development process should be started from Solutions as it makes the deployment easier from one environment to another environment with the help of Environment variables. It makes the deployment super easy as right from the development phase we can use variables wherever necessary and while deployment we change the values of the environment variable to point to the current environment.

• Screen size should be determined in the initial stage of development as in a later stage if you adjust the width of the screen form will get collapsed. Normal screen height can be set to a maximum of 2160 px if the form requires more than that, directly jump on to a scrollable screen as it offers much flexibility by providing the scroll bar if the form height increases.

• This is one of the important part of PowerApps, There are multiple events available on page load so one must be sure about the execution order of the load events, the events are App event(App onstart), Sharepoint integration events(onNew, onEdit, onView), screen event(Screen Visible). So an in-depth understanding of these events are required for a better solution.

• As we discussed in the earlier post for the infinite loop scenario if the form does not have PowerApps form we cannot update the flag column values on the new form and edit form. Since, we cannot customize the modern OOTB Sharepoint form it will not allow adding any javascript on form load to set values for the flag columns. To overcome that scenario. Before moving into the solution thanks to SharePoint for providing multiple endpoints to get and post records to list and libraries, we can take help from CSOM clientsvc.bin methods and construct a process query for “System Update”. It is a similar method to the set field action from SharePoint designer.

• Error handling is a significant part of any web application. It makes the application more user-friendly.
  • For PowerApps – By default all the data cards will have the Required field property and by using the “formName.Valid” we can trigger the error messages. On the other hand, we would be using custom validations like Email or Phone number. For such scenarios with the help of variable conditions, that can be set for border color, error labels and Notify.Error a common message is displayed on top of the screen. There is more to this topic to be detailed about later.

• For Power Automate – We have the “Configure run after” option in each action’s settings. We can draw parallel actions for the failed and time out scenario. Conventional Try, Catch block can also be implemented using “Scope” action in Power Automate, we will see error handling for Power Automate in detail later.

Please leave your valuable comments and suggestions, Happy Building 🙂