PowerApps native code Versus offloading to Power Automate

[Gary_Eden]

We have a debate going on between members of my Power Platform developer team and we are pretty much split down the middle.

The debate is when should you off-load actions from Power Apps to Power Automate.

The divide is split around which performs faster/better and which is more stable/reliable/easier to fix.

I expect there is no absolute but the current debate revolves around sending email confirmations following user actions within an app (in this example reserving a desk in our desk booking app).

The current set up is sending the composed email using Office365Outlook.SendEmailV2(), there are several options and dynamic values that are collected as part of the composing process. These values (plus a few extra ones) are saved to either Dataverse or Azure SQL (the app can run on either), on success the email is sent - the patch is wrapped in a variable (if empty the patch failed and an error message is displayed).

The argument for using the PowerApp to send the email is that all the information is there at the moment of execution, so it makes sense to send the email as part of a single transaction, on success.

The argument for using Power Automate is to take the load away from the app and apply a trigger on the database to start the Flow, collect the data (that's just been saved in the table) and then send the email.

I've tried to be unbiased in the above but to be open, I'm for using Office365Outlook.SendEmailV2() as I've had too many experiences with Flows breaking following Microsoft updates, plus it's easy to add extra bits later on if needed. 

I do use flow from time to time and I'm open minded about changing over if there is an overwhelming and convincing reason to switch over from using Office365Outlook.SendEmailV2() and similar.

[cchannon]

I, too, generally prefer to keep the logic within PowerFx where possible. A couple additional reasons you didn't mention:

• Flow runs aren't free. Once you reach your monthly cap based on user headcount you need to start paying for additional runs
• Offloading to Flow adds moving pieces to the solution; your flow needs to be in the environment, it needs to be turned On, the user needs to have appropriate privs to execute it...

[TheRobRush]

I, personally, find that complex requests tend to be better in PowerAutomate but I assume most  people will have their own opinion case by case. I've never had a flow break, a little curious what actions you take where that has been a common issue. Sending a lot of data via PowerApps can faill slightly more often due to hiccups/drops in signal etc and I find it's just often more reliable to send one small bit of data, a record ID, or a json string with a few bits of the data, and then letting powerautomate handle it all in the cloud where there is no reliance on signal strength.

[Gary_Eden]

Two replies and it's 50/50.

Valid points for both approaches.

Interestingly for the forum the answer is 'it depends', there isn't any right or wrong way and I suspect there is no compelling argument to use one route over the other.

For others who may find this post, I won't accept one as a solution as they could be both correct or both wrong... it simply depends.

The important thing is 'does it work', if it does it's most likely the right solution for your specific instance.

I'm sure the debate will continue within my team for a long time to come.

[TheRobRush]

100% it is for sure a per use question.

And in some cases the answer can even be BOTH.

For example. I have one high traffic app. It has to be precise, and we cannot wait on it. It scans in arrivals in a garage, that is about 50 feet underground, and under who knows how thick a layer of concrete as it is below about 5 other levels of garage. During testing I found that it could, on occasion be an issue.

So in this scenarios the model I rolled out incorporated the ID number of the record associated with the parking pass, arrival date, location etc into the QR code so the initial scan at user level would have the most pertinent information baked physically right there into the code. It then wraps a normal patch into an IfError(Patch()) so that if that fails it drops this scan info into a local collection and turns on a time that begins running and every 5 seconds checks to see if the 'Queue' collection is empty, if it is not it sends the next item in the queue to flow, and if the flow returns back a success notification it removes this item from the Queue, timer keeps running and it checks again in case there are multiple items queued. When it sees queue is empty it then turns the timer off until another failure happens starting it off running again.

Might be a little overkill, but in that specific situation it brought me some piece of mind, and after those few failures that prompted this in the exploration/testing phase since launching with these methods in place to handle unexpected drops in signal etc there has not been a single failure usage wise in over a year now. So, for me, worth that little extra work when setting up.