When deciding on the correct type of the Power App we ask questions. Types of questions vary from the flow to UI. Flow is important, but first what customers see is the UI. The Canvas app allows us to create a very flexible interface. So, it becomes a choice number. But before making a final decision – consider all the limitations, pros and cons of Canvas and Model-driven apps.
In general, Canvas applications are mainly for field workers who use phones or tablets to write and read information. Model-driven applications are for computers. They are limited in the interface transformations but empowered by standard UI builder and driven by the data model. You can save some time by building more complicated flows.
Other than that – go through the Power Apps Canvas to make a final choice.
Limitations of data volume available to load in canvas. Ways to overcome this limitation.
-> The default limit of data loaded from a data source is 500 rows. This can be changed to 2000 rows from advanced settings in power Apps. This limit applies when non-delegable queries are used.
-> To overcome this limitation, we can use delegation. In delegation, the queries would be performed by the source of the data. Delegation is supported by Sharepoint, Dataverse, SQL server and more. Delegation in simple words is that the task is not performed by Power App but instead by the data sources.
-> Not all functions are delegable in the above data sources. Some of the delegable functions are Filter, Search, LookUp, Sort, Sum, Max, etc. Some Non-delegable functions are First, FirstN, Last, CountIf, Collect, ClearCollect, etc.
-> If we use a non-delegable function, we might receive a delegation warning and the data received by that function would be a subset of whole data if we use a function that is not supported by a data source. If we have a very large dataset, we can create static views instead of using whole data and use those views to get the result.
-> If delegation is not possible in certain cases there is also another workaround of using a combination of other delegable functions or Power Automate to get data from the source and then display it in the Power App. Also, there is a way to obtain data in batches and iterate over the whole list to obtain data in chunks of 2000 rows.
Limitation of a number of controls. Ways to overcome this limitation.
-> There is no limit on the number of controls, but it is recommended that we should use less than 500 controls in one app. The reason for this is because Power App generates HTML document objects to render each control, that’s why when we add more controls the generation time for those controls increases.
-> To overcome such a limit, we can use certain controls like gallery/data table instead of individual controls wherever repetition is present because it will not render each and every control multiple times. Also, components can be used to design templates of controls if they must be used at multiple places.
-> Some controls like PDF viewer, combo box, and data table already have a slower loading time due to their large scripts, so we need to place such controls on a screen where multiple controls are not present thereby reducing the amount of time required for loading of that screen.
Limitations of data sources. Ways to overcome this limitation.
-> There is no limit on the number of data sources that can be added to one app but it is recommended not to add more than 30 data sources in 1 app. New users need to sign in to every connector and so it increases the startup time. Plus, each connector requires CPU resources, memory, and network bandwidth whenever data is requested from the source.
-> There are various limitations based on the data source chosen. Here are some of the data source connectors and their limitations.
I. SQL Server Connector –
-> N+1 Query – This happens when the gallery control generates many requests to servers. To avoid this problem, we can use View objects in back-end SQL.
-> Table Scan instead of index seek – This will slow the app if we run queries and the database would scan the whole table instead of index seek. To avoid such problems, we can use StartsWith in the formula.
-> Thick client or excessive requests – When the app performs operations on the client-side and the client devices are not powerful enough, this will create such a problem and slow the app. To avoid this issue, we should create a view object in the SQL database. This also solves the N+1 problem.
II. SharePoint Connector –
-> Picture Column and attachment – The size of the image stored may slow down the response while retrieval of data by the client. To ensure this doesn’t happen try only to use this column when necessary. Plus, we need to enable the explicit column selection feature to query only the required columns.
-> Large lists – large lists will slow down the app when querying the table. We can split the list into multiple smaller lists based on parameters that can be used by the app.
III. Dataverse –
-> App will perform slower if the functions used are client sided instead of server sided. We can use Dataverse views to reduce the overhead of using the whole table.
IV. Excel Connector –
-> Main limitation of the excel data source is that it has a very limited number of delegable functions which would restrict apps to loading data less than 2000 records only. For this case, we can use other data sources.
There are various other connectors(data sources) and all will have certain limitations attached to them, so we need to choose data sources based on our requirements.
What are the consequences when exceeding the limits? – how users understand that and which actions are required.
When a user exceeds certain limits, it reduces the performance of the app drastically. App start loading time and screen navigation load time might increase and users may face lag while operating the app. Also, non-delegable functions might result in data loss and certain data which might be important for the user to see, would not be available.
There is an App Checker available in Power App from where we can see the health of our Power App in the form of errors, warnings, suggestions, etc. Developers should keep checking that section for any delegation/performance issues as a measure to avoid the consequences.
Here are some best practices for fitting in the limitations.
Use local variables instead of global variables wherever possible as global variables are shared across all the screens and there could be some screens where they are not used. So there is no point in unnecessarily loading them everywhere.
To significantly improve performance, the Concurrent function can be used to execute pieces of code parallelly which are independent of each other so that one code execution does not block the execution of the code following it. The code written outside the concurrent function will execute serially after the concurrent function finishes executing.
If any small data source is to be used again and again throughout the app, then it can be loaded into a collection on the App Onstart itself, and that collection can be repetitively used everywhere in the app. This would significantly reduce the number of unnecessary network calls.
Find more blogs on Power Platform Week.
About the Author:
Microsoft MVP ❖ Senior Software Engineer at LogiqApps ASI am a Senior Full Stack Software Engineer with a demonstrated history of working in the information technology and services industry. Skilled in Dynamics 365, Power Apps, Power Apps Portals, Power BI, Azure services. I am an active member and a Power Platform community lead, and in 2022 received a Microsoft Most Valuable Professional (MVP) in Business Application award for the leadership in the Dynamics community.
Reference:
Akinfiieva, E. (2022). When and how to use Power Apps Canvas. Available at: https://elizabeths365blog.com/2022/04/when-and-how-to-use-power-apps-canvas/ [Accessed: 24th January 2023].
