Even if PowerApps truly is a low-development option for building applications, it would still be important to approach application development with best practices that are normally applied in other development technologies. For anyone who has developed applications in the past through any programming language, such tips might be already known or have now even became obvious. However, in this blog series, I will be collating some guidelines which will be useful when developing a PowerApps (and probably any other) application.
Even if PowerApps may provide a more controlled way of designing and developing an application, and an easy approach of adding more features as you get along – care should be taken when developing extensive applications which are composed of many screens, features and functions (in the same way as any other application development technology). It is hard to generalize and suggest a one size fits all approach for all PowerApps use cases. However, I personally found it helpful to start with having a draft UX design of all screens setup and run by the end-users/ stakeholders before going through the application of the logic itself.
Although PowerApps is a low-development technology, some level of coding and logic is still required. And in cases where this logic needs to do more than just a Submit(Form) or a simple Patch() command, thought would need to be applied in almost the same way as developing an application with other technologies. For instance, there are cases where variables need to be reset through the OnVisible() attribute of a screen (so that when a screen loads, the variables are fresh to be re-used). There are cases where a Refresh() needs to be done – for example right after an update to a SQL database, if the latest added record needs to be shown in a Gallery or other lists. And such commands need to be implemented based on the design and user journey that exists in an application.
Being too agile in developing a PowerApps application might increase the risk of technical debt. One additional step in the middle of the user journey, requested when the basis of the application and its logic have been applied, might mean that what has been properly developed and worked, is now to obsolete from a logic perspective. Hence rework needs to be applied, increasing risks of mistakes, bugs or flaws.
Likewise, what has been tested and approved before, now needs to be retested from a functional, UX state and unit testing point of view. This means that one slight addition of a feature (maybe another update or just a change of a background colour of a label/ button depending on a validation/ boolean check), could trigger far more indirect effort to ensure the application still satisfies scope and quality.
Like any type of coding, hardcoding when building a PowerApps application might not be the best practice and hence is ideally avoided. Through hardcoding, assumptions are being done during development stage that the application coding will remain static and any values being used or referred to within it are not going to change. For example, a filter is done on a hardcoded value of an organization name directly within the code, like Filter(OrganizationTable, OrganizationName = “CurrentName”). A change in the name will require a revision of the code, whereas if the check was being done using the record’s key in the database or a populated variable (rather then the value itself), the change of value would only be required within the database.
In a similar manner it is important to adapt this logic approach to any areas where potential additions or changes in the future might occur. So for instance, let’s say an If condition is going to be done within the program to only enable a button when a value is positive. And let’s assume the positive and negative value are being picked from a junk dimension or any other table. It might be that at the time of developing the application, there are only two values present: a positive and a negative value – i.e. “Yes” and “No”. If the button needs to be only visible when the value is positive, there are two ways of writing the If condition:
· If(Variable <> “No”, DisplayMode.Edit, DisplayMode.Disabled)
· If(Variable = “Yes”, DisplayMode.Edit, DisplayMode.Disabled)
At the point of development both commands are going to return the same result. However in the event that in the future a neutral value is added – let’s say “Maybe” – and some conditional checks might hence include any of “Yes”, “Maybe” and “No” – the results of the conditional check might be skewed if we had applied the first command. This is because the button will be enabled both when the value is “Yes” and also when its “Maybe”, whereas the button was required to only be enabled on “Yes”. Now when the same developer might be maintaining this application and the database, and the number of screens is minimal or with limited coding logic, one might argue that the command can easily be changed within the application coding and a new version of the application is published. However as best practice, it is always advisable to develop the application with the scope of doing minimal changes to the coding, as there might be derived effects of a simple change on other functionality in addition to the potential need of having the entire application re-tested (especially if we are dealing with a sizeable application).
As with any other development tool and language, it is a good practice to comment the coding applied in the different screens.
With PowerApps application (like other technologies) having higher chances of being developed by one person/s and maintained (now or in the future) by other person/s, troubleshooting issues or even judging the effect of a future change will become harder without commented code. PowerApps comments start with // and adding simple comments like “//Refreshing datasource to get latest data in Gallery GalleryName post-patch to its datasource DataSourceName” might be enough for a different developer to realise why that command should be or not be changed (and the tester to know what to focus on if that is changed after all).
Testing, testing, testing
A developed application is going to be used by different users, and in cases where the application is not a two-screen application, different user journeys might exist. Also using the logic path of the application might be different depending on the user behaviour, and especially in cases where If…Else conditions are being used. In such scenarios, it is even more important to ensure the application has been tested over and over, and preferably by different persons (to ensure different perspectives and behaviours) hence increasing the chances of covering as much user journeys and logic paths as possible. As with any other technology, the use of testing logs is suggested to keep track of the flaws, bugs or improvements noted and if possible the pattern of reproducing that error is also noted.
In cases where different navigation options exist (like back and forward from each page in addition to a normal menu), one should not underestimate the importance of re-testing following successful runs, trying different combinations or patterns, especially if variables are being passed from one screen to the other.
In a following blog within this series, to be released soon we will continue to cover more points related to PowerApps and application development – also highlighting PowerApps specific pitfalls worth avoiding! As always feel free to reach out with any feedback or clarification required on any of the above points either through our blog itself or on Twitter: @bonello_jason