What types of apps is PowerApps appropriate for?

[whitekn3]

I have a lot of experience with Access VBA, C++ development, and limited experience with C# and XAMARIN Forms.  I am brand new to PowerApps.  I am interested in learning more about PowerApps and have a project that would involve about 10 lookup  tables, 4 or 5 main tables, Two moderate forms  (Sub forms, simple code), and several single table minor forms for maintaing the lookup tables. 

Does this sound like something  PowerApps could handle?

Any limitations? Gotchas? I ought to be aware of before using PowerApps?  At what level of complexity does it choke?

[Meneghino]

You can do all that you require except return a result, I believe.  At least it was not possible a little while back, but I am pretty sure that it will be at some point.

[Anonymous]

Hi @whitekn3

I'm joining the conversation here just to point out that lately we have manged to build more and more complex apps than it was possible an year ago. The pace at which this product is evolving is amazing (ignoring the temporary hiccups that sometimes happens after an update)!

For example, I have just finished doing a quite complex app that was intended to track the progress of a new starter in the company that has to go through different stages. The app ended having about 10 screens, each screen being a template for different types of forms (surveys, checklists, etc.) which at run-time are being dynamically populated with questions, information, stored in an Azure DB (a databse with around 28 tables that are all used in the app with no performance issues).

We have also used PowerApps to connect to SharePoint for mainly gathering data from users, taking pictures, creating multiple items at a time, etc.

The product is definitely getting better and better, but as I said in the beginning there are times when things break because of updates, which might make you think that the platform is not exactly stable.

[whitekn3]

Reminds me of Access 2.0 back in the dark ages.  Access 97 was a game changer.

[Anonymous]

Actually ... Access 2.0 was a game changer from Access 1.0 and 1.1, both of which I still have the diskettes 🙂

And yes A97 was a game changer. A95 was a disaster !

[whitekn3]

I deliberately said 2.0 instead of 1.0 because my feel from the conversation is that PowersApps is usable, like 2.0 was.  I did not think Access 1.x was usable (I was using Pascal and Paradox at the time.)  Obviously, some did think 1.0 was usable, as I ran across an Access DB written with 1.1 around 2005 that was still in use!

Access 97 was the first version that I thought was good enough for serious work, though I wrote several 3.0 apps.  But then, there are still some C programmers who don't think any thing but C is usable. <g>

[JRaasumaa]

---

@Meneghino wrote:

Actually I only work with Azure SQL DB, and I have seen somewhere that you cannot call stored procedures in on-premises SQL Server, but that may be resolved by now.

---

It's definitely resolved, we are using this to do some heavy data sifting right at the database level instead of trying to drive it through the app.

[JRaasumaa]

---

@Anonymous wrote:

Keep in mind that PowerApps are geared for Smart Phones ( mobile) and Tablets. So, those screens are only so big ... and you can basically only view one screen at a time.

I've been working with Access 24x7x365 (lol at this) since 1992. I've built some rather complex 'apps'. Most of these would not even remotely be doable in Power Apps, although some 'subset' of an app might be.

Also condsider that at this time, there is a 500 record limit that can be returned directly from a data source. Wherein there are some ways around this using 'Delegation', this may be a big limitation. But then again, mobile are not nearly as fast as laptops (etc) in this context.

===

---

PowerApps on a desktop works absolutely fine through the browser.

We have users that only open our primary app through a web browser and if their pages are formatted with more of a desktop solution in mind (smaller buttons, smaller text, more info on the screen etc.) it's quite effective.

As for the 500 record limit this can be overcome in a multitude of ways. Even just putting the data into a gallery directly without collecting it will overcome this. We have a few screens that just show the actual datasource and while it's not as fast it certainly works.

Overall PowerApps is a good simple solution to data collecting and viewing but you'll find it very lacking for complex solutions unless you develop workarounds or sacrifice features for function. Specifically the lack of uploading or viewing Sharepoint files easily is the biggest hurdle and simple things like capturing an image (pen, camera, attaching) can be a massive headache to work with currently.

[Anonymous]

 @JRaasumaa

" but you'll find it very lacking for complex solutions unless you develop workarounds or sacrifice features for function"

Well ... that's pretty much what I was saying. But I do agree that PowerApps in the browser opens up a lot more functionality ... especially since it is integrated with many O365 apps, as well as data sources / connectors ... whereas Access is not per se.

[Anonymous]

@Meneghino 

At this link:

https://baizini-it.com/blog/index.php/2017/09/28/powerapps-and-azure-sql-database-current-issues/

(thanks for the link btw)

Regarding:

3. Fields cannot be updated with null/blank values

There are two possible work-arounds:

This strikes me as a serious BUG. So, this is saying that ... from within Power Apps ... say you are Submitting a Form ... not all fields are required ... and you leave a field 'blank' (ie Null) ... this cannot be written to a Field that accepts Nulls in an Azure SQL DB?  If so... WOW!

I know I can write Nulls to my On Prem SQL Server db .

[JRaasumaa]

---

@Anonymous wrote:

@Meneghino 

At this link:

https://baizini-it.com/blog/index.php/2017/09/28/powerapps-and-azure-sql-database-current-issues/

(thanks for the link btw)

Regarding:

3. Fields cannot be updated with null/blank values

There are two possible work-arounds:

This strikes me as a serious BUG. So, this is saying that ... from within Power Apps ... say you are Submitting a Form ... not all fields are required ... and you leave a field 'blank' (ie Null) ... this cannot be written to a Field that accepts Nulls in an Azure SQL DB?  If so... WOW!

I know I can write Nulls to my On Prem SQL Server db .

---

Not writing null fields is not a bug, it's just not supported to write the value Null to a field in SQL. This does not mean if you are submitting a form that the required fields would be left blank, that's up to your design and how you want the data to be written and what error checking you have in place to stop the lack of a value from being written. You could write your app to write a blank value "" or 0 to an integer field etc. it just cannot be a Null value.

From Microsoft:

https://technet.microsoft.com/en-us/library/ms191504(v=sql.105).aspx

"A value of NULL indicates that the value is unknown."

Nothing is stopping you from protecting your data entry with good programming 🙂