Tuesday 6 February 2018

PowerApps–the good, the bad and the ugly (early 2018)

I’ve been doing quite a lot of work with PowerApps for clients recently, and it’s been an interesting time. No doubt I’m still not the world’s most capable PowerApps implementer by any stretch of the imagination, but I feel like I’ve been through the usual denial/anger/acceptance phases that often come with a new technology ;) Some of my work has centred on a proof-of-concept application for one of the big airlines – specifically, building an app that pilots should be able to use whilst offline on an iPad. The project was to digitise some forms related to booking leave, which is an important part of flight crew scheduling. We effectively rolled 3 forms into one app:


I gave a presentation on this recently to my colleagues at Content and Code, but I’ve also genericised some of the information so it can be shared more widely (Contoso Airlines!). The deck shared below is a combination of some typical lessons learnt and tips, but also has my thoughts on where PowerApps is a technology, structured into “the good, the bad and the ugly”.

Potentially transformative, but with a learning curve..

My conclusions are that it’s a great technology and although it’s aimed at forms-type applications in general, it really shines for relatively simple mobile apps. The organization just has to deal with getting users to have the PowerApps app installed (either from the app store, via an MDM solution such as Intune or Airwatch, or another approach) and then all the PowerApps forms and applications the organization provides will show up there. This is *far* easier and cheaper than developing individual native apps on iOS and Android, which each need to be distributed to users once the build is complete. In contrast, it’s feasible that you could have your Office 365 users working with a simple PowerApp on their mobile device within hours. Think about that for a moment! Sure, PowerApps doesn’t give you the richness that a high-end native app can have, but the barrier to entry is much lower.

However, it’s not always the simplest for the app implementer to work with. Frequently, things can get into a territory that I’d argue most power users would struggle with. An example in my case was having to abandon the default SharePoint integration/data-handling, and craft my own formulas which use the Patch() function to add an item to a SharePoint list (necessary because my form used multiple screens). This is fiddly work if you have lots of form fields and columns in the underlying list, even for a developer used to such things.

Customizing SharePoint lists vs. creating a standalone PowerApp

The implementer must choose between two approaches – customizing the form of a SharePoint list, or creating a “standalone” PowerApp (which might talk to the very same list). Conceptually these are quite different, and have different behaviours. This decision is expressed in the PowerApps menu on a SharePoint list:


A key thing here is that customized SharePoint forms do not show up in the PowerApps app:


If users need to work with a customized SharePoint list on their mobile device, then using the SharePoint mobile app instead provides a reasonable experience – in fact, the SharePoint app should hand-off to the PowerApps app when you go to the list, and the customized PowerApps form should then be loaded. However, this currently seems to be a bit hit and miss – most often, I actually just get a web rendered view of the PowerApp, and here it seems that the experience isn’t as optimized for mobile as a true PowerApp – some pinching/zooming is often necessary.

I’m sure things will be straightened out here eventually, but I still think I’d prefer a different model – what about if certain customized SharePoint lists could be flagged to appear within the PowerApps app (perhaps by a tenant administrator)? That would seem a better arrangement to me at least.. 

Other interesting aspects

The presentation includes some high-level detail on other things I’ve worked with that might be interesting:

  • Installing the on-premises Data Gateway to connect to on-premises data (SQL Server in my case)
  • Implementing offline support in a PowerApp (using a Timer control to submit data once reconnected)
  • Some implementation details around using a Gallery control for navigation, and the 10 PowerApps functions I found most useful from the 150+ functions which are available

My “good, bad and ugly” summary:

If you’re not that interested in the presentation and want to skip straight to the summary, here are my conclusion slides:




By the way, if you’re wondering what I mean by “web experience (upscaled phone/tablet view)”, let me try to explain. Certainly a form/app looks good on a mobile device, and is optimized for that form factor – all the controls are very “thumb-able”, and even typing into a textbox works fine (shown here at tablet/iPad size):

4 - BA PowerApp - paternity leave screen

But when a PowerApp is accessed on a PC, there is no responsive design or optimization for the device – the very same rendering for phone/tablet is used, which is just plain weird in my view:

PowerApps - PC 800 - msg

And no, I don’t know the Office 365 suite bar displays “Dynamics 365” either (particularly since Dynamics is not even in use in this tenant). But I’d happily live with that if I could have a better experience than the strange “phone screen in a PC browser” deal that we currently get. Nintex Forms does a better job of this, so I’m not sure why PowerApps went down this route. Again, I’m hopeful some enhancements to this will appear at some point.

So that's some headlines from what I spoke about. I'll most likely publish some other PowerApps articles which dive into more detail on implementing offline/using the on-premises Data Gateway etc., but essentially I just wanted to share the slide deck in case it’s useful to anyone:

The slide deck:


Thangu said...

Very nice and informative. Thanks for your wonderful SharePoint articles since 2007.

Chris O'Brien said...


Thanks! You're making me feel old now ;)



Unknown said...

Hi Chris, just wanted to mention that the on-premises data gateway now supports clustering so it isn't a single point of failure anymore... https://powerapps.microsoft.com/en-us/blog/gateway-high-availability-for-powerapps-and-flow/

Lukas Sauerwald said...

Nice Article! If you configure a PowerApp to automatically scale to a Display you will be able to get rid of black bars on mobile devices. That also means that when opening a phone optimized PowerApp in a browser the PowerApp will scale but it just looks horrible. Unfortunately there is no way of creating one phone and one web PowerApp and have the right one chosen automatically. I usually create two PowerApps then but that leaves me in the Dilemma of properly naming them ...

Chris O'Brien said...


Ah, good info - thanks for letting me know. Clustering of the gateway is a big step forward..



Chris O'Brien said...


Yes, that's how I see it too. There's just no great option right now for having a single version of the app which is optimized for PC browser *as well* as tablet/phone. Often not a deal-breaker if the app is predominantly used on one or the other, but would be nice to have the best of both worlds..



Mark Wilson said...

Hi Chris, have you identified situations where you would have to upgrade to PowerApps Plan 1 or Plan 2? Starts to get expensive on those plans...

Kelly Jones said...

Great article.

One question I have: from what I understand, a PowerApp (or a Flow) is tied to a specific user account. What happens if that user account is deleted?

We often see SharePoint sites abandoned because the site owner leaves the company and doesn't transfer ownership before they leave. In those cases, a SharePoint admin can set a new owner -- is there a similar option with PowerApps?

Chris O'Brien said...


Not really - I haven't found a need to use the Common Data Service yet (which pushes you to Plan 2). I could imagine that once a big enterprise has been using PowerApps for a few months though, the benefits of this grow e.g. centralized data across apps.

Similarly, the connectors I've been using are the ones which come for free on Office 365 plans - no need for external cloud services yet. And in any case, I think some small custom code to interface with such a service could be more efficient if "pro" dev skills can be brought into the mix.