MISSION CRITICAL: Is PowerApps ready?

[ericonline]

Hello,

Resuming the conversation that was originally posted 5 months ago which received great input from the community. Checking the pulse 5 months later. Has the sentiment changed?

• Do you believe PowerApps is sufficiently hardened at this point in its development to handle mission-critical applications for your organization?
• Why or why not?
• What are your specific concerns? (availability, bugs, IDE, security, features, other?)

Feel free to define "mission-critical" in your organizations own terms. Thanks for the input PowerApps community. You. All. Rock!

[vangrieg]

I've been using PowerApps and Flow for a few months now for fairly "mission critical", i.e. main business process-related tasks, and found them fairly robust, with a few caveats: 

Sometimes connectors (especially SharePoint) just log me out, triggering MFA. This isn't that bad of an issue with PowerApps as it is with Flow, since in the latter case Flows just start to fail, and I wake up to see an email full of notifications about failed Flows. And then I have to go and reauthenticate each and every "broken" connection. If you have a policy of periodic mandatory password changes, you have to do it with every connector every once in a while. And until you do that, things will silently fail. 

Now, that's Flow, you might say, not PowerApps. Well, yes, but there's a "but". The way PowerApps work with SharePoint is that only users that have explicit permissions for a certain list or library can use the PowerApps connected to it. Makes sense, right? Except if you want to user PowerApps to validate, filter and otherwise restrict what people can do with the data. And if they have direct access to the data source they can just go and change things directly. Which can break everything. The problem here is that PowerApps, as far as I understand, cannot "run as" another user. So you can in some cases use Flow to do asynchronous background tasks for you, although to do that, Flows should be triggered by something else, not the app itself (i.e. when a new item is added to a SharePoint list). But Flows sometimes silently break... Granted, not many users can find a data source that's not in the main site navigation. But still. 

The whole sharing process is clunky and somewhat unpredictable. When you share an app, how will connectors behave? It depends. Some force users to authenticate (which is fine unless you have 5 connectors in an app, which makes things really annoying). Some just work. Some work as if I were using the app... Totally weird. And until you share an app you don't even know what will happen. There must be a system to the madness, but I don't know what it is. 

Then there's the issue of "Premium" connectors and such stuff. Some time ago I added a Salesforce connector and a CDS data source to a Flow. Mainly to see how they work, what CDS is and what useful data I can get from Salesforce. That triggered a 90-day Flow Plan 2 trial. I accepted it and forgot about it. Then, two months later, I used the Salesforce connector in an app (the connector already existed, obviously). Cool, except last week I realized that if I share the app, users will need paid plans as well, and that's just not realistic. Worse, what would happen is this - most would just click "Yes" to a Trial offer, and then be refused to be upgraded when the trial ends. My understanding is that our IT sees this whole PowerApps/Flow thing as a can of worms, sort of. When I started using them, they were cautiously okay with it - "let the silly child play if he wants to, he won't do anything anyway" kind of attitude. Now that I started using them for real things, they seem to be a bit worried - what with this triggering of paid Plans, and what if I succeed and share the knowledge and they'll get a flood of requests? 

Finally, there are issues with the development environment. It's terribly difficult to reuse code. It's terribly tedious and boring to change things - you can't search for all places where you used this or that formula/function. A few times I found that it's easier to rewrite everything from scratch rather than change a few things. And there are occasional bugs in Studio. And because you can't name versions, it's hard to track when you changed what. 

But, as you may have noticed, these issues aren't about how PowerApps actually work. Because in this department things have been surprisingly good for me. I can't recall a case when a Flow or a PowerApp would not work as expected after successful testing for the first time. 

[vangrieg]

Oh, and I completely forgot this: 

What will happen if I'm hit by a bus tomorrow morning? 

There must be a way to run mission critical apps as some sort of a system account, without an active O365 user. 

[ericonline]

@vangrieg, great feedback!  

Couple questions:

• What is the largest number of users you have deployed a PowerApp and/or Flow to?
• Are you actively logging reported issues? How many have you had since deployment?

Couple things that might be of use:

• RE: "...if they have direct access to the data source they can just go and change things directly.":
  • I had this problem as well. It was recommended to use "Target Audiences" in Sharepoint to keep people out of the Sharepoint Lists they have access to via PowerApps.
  • Only works with Sharepoint as a data source.
• RE: "...PowerApps, as far as I understand, cannot "run as" another user.:
  • We've instituted a form of "Service Accounts" like "PowerApps@mycompany.com". We are now trying to build all PowerApps and Flows with this generic account.
  • Should also help the "..hit by bus" scenario.
• RE: "The whole sharing process is clunky and somewhat unpredictable. "
  • We recently institutes AD Dynamic Roles by Job Title. This has been AWESOME.
  • Share the PowerApp with one (or more) Group (grouped by Job Titles)
  • When a User assumes a new Job and AD is updated (24hrs for our org) User automatically has perms on the app.
  • When User exits Job and AD is updated, perms are revoked
• RE: "Some force users to authenticate (which is fine unless you have 5 connectors in an app, which makes things really annoying)"
  • Agree. This is annoying. 
  • There is a set of PowerApps PowerShell cmdlets that allow you to turn off some of these popups
  • Mileage may vary. Especially for those Data Sources you WANT users to auth to... don't turn those off 🙂
  • Also, you can't use the cmdlets to turn off SENSOR (Location, Camera) popups.
• RE: "Now that I started using them for real things, they seem to be a bit worried - what with this triggering of paid Plans, and what if I succeed and share the knowledge and they'll get a flood of requests?"
  • EXACT. SAME. BOAT.!! This is a challenging one to handle. No solution yet other than "hide the keys!"
• RE: "It's terribly difficult to reuse code. It's terribly tedious and boring to change things - you can't search for all places where you used this or that formula/function. A few times I found that it's easier to rewrite everything from scratch rather than change a few things. And there are occasional bugs in Studio. And because you can't name versions, it's hard to track when you changed what."
  • I've heard rumor that this will be easier in the near term. Some new tools coming out that allow you to export all your code, diff it, etc.
  • Can't wait for this!

Awesome, awesome feedback. Thank you for taking the time to write it out and share with everyone!

[Mike2500]

Just a quick reminder that the audiences trick will hide the lists from users, but is itself not a form of security. The users can still get to the lists if they want to.

I'm very interested in the rumor you've heard re improvements to the designer experience, as that's also been a source of frustration for me. As noted, trying to follow the logic of a complex form is tricky, as there isn't a single spot to see which variables are being set where. Also, it's clear that Power Apps is designed for small, mobile forms with only a few fields, but users want to port over their 50 field InfoPath forms, and this results in a really poor experience for the person building/maintaining the form unless there's a complete redesign  (not to mention Flow's lack of support for state machine workflows, "wait for change in current item", and performance issues with larger flows, all of which usually comes up in conversations regarding porting InfoPath solutions).

[BrianHFASPS]

---

@vangrieg wrote:

Oh, and I completely forgot this: 

What will happen if I'm hit by a bus tomorrow morning? 

There must be a way to run mission critical apps as some sort of a system account, without an active O365 user. 

---

I just built my first PowerApp and this is my worry. It is tied to my Office 365 account and not tied to the tennat in some way. Can we change ownership or something so others can access in need. Also what happens if I leave employer, does app live on somehow?

[vangrieg]

Thanks @ericonline, glad you found my post useful. 

To answer your questions - only a handful of people use the app, it's not a mass solution. And no, I'm not logging anything. To give you an idea - I'm a "people developer", don't work in IT, doing this isn't my job at all, have no training in software development or IT, so even though I have a few ideas about more universal apps, I won't go there exactly because there's no chance I'll have the time and energy to support the users, track bugs etc. Not to mention that I have a regular user account and can't really track usage, use AD features you mention to share the app, etc. Flow is serving a larger audience in my case, although, I think, nobody really knows that. 🙂 In any case, we're a global professional services firm with a few thousand employees, but I myself work in a country market leadership team with only a few dozen people. So not a large userbase at all. 

These things are "mission critical" though in that they are used in core functions of the business, so it's not some hobby joke thing. 

From my point of view, this is exactly the use case where PowerApps/Flow shine and can serve to fill a huge gap - we're too big to not have automation and, on the other hand, too small and with too diverse local market requirements, with a very specific set of business processes to have a single "big" solution to cover all our needs. 

[vangrieg]

---

@BrianHFASPS wrote:

Can we change ownership or something so others can access in need. Also what happens if I leave employer, does app live on somehow?

---

The way I understand it, f you leave the employer, your account will be terminated and therefore all your apps and flows will stop functioning, unless you share them with proper permissions in advance. 

I don't think you can change the owner of an app, but, IIRC, Microsoft said this may be introduced later. 

[martinav]

No.  It is not.

In brief:

1. Far too many down-time issues.
2. Far too many things change that require me to change my code to "work-around" new issues from PA updates.
3. I have no way to hand this off to anyone to support.
4. Large companies wont touch it due to security issues.

[cofordpa]

@martinav 

I've been using PA for a short period now.  Many features I'm impressed with, but the down-times are concerning.  

There seems to be a massive failure today (May 2nd), how frequent would you say these down-time events occur?  

I'm getting rather nervous about deployment..