If I create 1 PowerApp with Multiple connector which requires 60-70 screens.
In this case, what is advisable? should we good to create in straight way or we should divide the functionality in 2 Apps (30-30 screen) and deeplink 2 Apps.
What will be fast and best way to do.
I personally believe that, 60 screen does not take much time to load the App.
Looking forward to see all mentors opinion.
Thanks & Regards,
Unless you have 70 connectors (and even then I don't agree) you should not have 60-70 screens, you should use logic on a small number of screens to differentiate between what connectors are being used and what to display and what functions are triggered/used.
Could you provide some more detail as to why you think 60-70 screens is required? We may be able to give you some guidance on how to reduce that.
The concern is not necessarily on load time, it is more about maintainability - if you have 60-70 similar screens then every small change will become 60-70 small changes instead of one or two.
Agreed 100% with @iAm_ManCat. I wanted to chime in and mention there is a soft limit of 500 controls in a single app after which point your performance will begin to degrade. Your suggested quantity of screens would almost definitely exceed the limit. If you'd like to read more on this topic I've put a link to the article below.
PowerApps Blog: Optimize canvas-app performance in PowerApps:
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."
Thanks for the reminder of the 500 control soft limit. Though, if you use the wizard to create an app, you get three screens: edit, display, and gallery. Both the edit and display screens use forms, which have cards, which in turn have multiple controls. Simple math shows that with 60 fields, the soft limit of 500 controls will be exceeded. Or, am I making some incorrect assumptions about what constitutes a control?
Here is a definitive list of controls in the PowerApps Documentation
So yes, apps with built with the wizard that have more than 60 fields are violating the guidance. I just created a separate thread on this to see if others have suggestions/thoughts. I've previously commented on performance issues, but hadn't previously done the math to notice that my apps certainly exceeded that 500 number.
..Also want to add that I'm fairly sure gallery controls only count as the number of controls within your first Item, the rest are not technically there otherwise almost no App out there would fall within the limits after x number of displayed rows!
So my understanding was that a gallery with ten controls in it is eleven controls in total, so in your case a gallery with 60 controls is 61 controls. This is obviously still quite large.
60 x2 for title and value within in display forms
60 x3 +- for title, value and error message
(and if you have 60 required fields then x4, but you could reduce that back down to 3 by making the title Text conditional "* Title" or "Title" on whether the card is set to required)
60 +1 for Display Gallery + 1 if you keep the divider and +1 if you keep the arrow.
Total: 363 (excluding menu bars and icons)
Total: 363 +7 for Browse Screen menu +5 for Detail Screen menu +4 for Edit Screen menu
Could I also ask why 60 fields are needed? You don't need to go into specific details, I'm just trying to understand how we reached this point, as I feel like the way the data is stored could also be part of the problem, but don't know without understanding further.
Thanks @mdevaney for sharing the performance link, that's always a good reference point for how to keep your Apps tidy 😸
My math included three controls per field for the display form, as the card itself is a control. For each field in an edit form, it's five: card, title, value, error, and required indicator. My math lines up with yours for the gallery, though I did include the various menus, navigation controls, etc.
Why 60? One example is that I will be migrating an InfoPath form that's a series of about 100 questions, grouped into several categories for a type of a site report. I didn't build this one, but this looks like a pretty typical form to me. And note the "page 1 of 5" at the top. I've created many forms that required a multi-level approval process, where approval info was captured for each stage. (this doesn't require 60 fields, but it does add a dozen or so to many forms.)
InfoPath actually had a great system for organizing fields in complex forms, where fields were grouped into folders. It was simple and easy to deal with forms that had 100+ fields.
Yeah sounds like InfoPath was good for that, and yes you are right about the numbers, I did not include the cards themselves so that would be a bit more (it is a soft limit though)
Since this is just a larger form you're replicating, have you considered using Microsoft Forms Pro and then attaching that to Power Automate? You could have as many questions as you want that way and it would be just one control 🤔
I probably wouldn't use PowerApps in the way you have if there was a mandatory 60 question form being replicated, in the same way I wouldn't try use a spanner to unscrew a nail - no point struggling when there's another tool for the job.
So aside from that and going back to your original question of whether to split - If you must use PowerApps for whatever reason, I would have a separate App for each form in this case only, then have one 'Form List' standalone PowerApp that launches the other Apps 🤓
Forms is for submitting, and doesn't allow for opening existing entries, modifications, approvals, etc.
So you mention that there's no point struggling when there's another tool for the job, but there isn't. At least, not from Microsoft.
Check it out!
Fill out a quick form to claim your user group badge now!
Find out where you can attend!
Features releasing from October 2019 through March 2020
The largest Power BI, Power Platform, and Data conference in New Zealand