Introduction

We’ve previously on this blog covered Power Apps write-back for Power BI/Fabric comprehensively, and in the past months we’ve taken a stab at the Fabric Native solution: Translytical Task Flows.

However, when comparing the different options, which solution actually comes out on top?

The answer is, as always, it depends.

Each of the sections below attempts to cover one topic at a time, but there is some overlap, as they are hard to treat fully independently.

End User Experience

Which solution works best for end-users, assuming that the solution is well-crafted and that we don’t need to consider backend complexity and costs?

Translytical Task Flows:

TFFs are really quite limited in their front end capabilities currently (hopefully this changes in the future).

Input Options: Today you only have three slicers types to choose from for generating user input (List, Text and Button), with no options for e.g. Sliders & Date Pickers, which limits the options for end users greatly. Further, the Text Slicer is impossible to default to a value, which makes the User Experience when editing records poor.

Buttons: The buttons which pick up inputs can pretty easily be altered conditionally by state (default/clicked/disabled etc), and through clever use of bookmarks and field parameters we can make both inputs and buttons behave somewhat dynamic, showing/hiding/disabling fields and buttons on conditions. But in reality we are jumping through hoops here to make something that has a minimum level of application-like behaviour. And the cost is a very complex myriad of settings, bookmarks, parameters and calculations.

Communication with User: There is one big upside for TTFs however: The native Power BI integration includes well-integrated notifications and messages between application and user when the user submits data – as long as you configure proper return-messages in the User Data Function that is… But awesome that this works so well.

Power Apps

Power Apps easily solves most of the UI/UX issues above.

Input Options: There are way more input types to choose from, and they are much more customizable. You can present the user with Date Pickers, Sliders, Radio Buttons, set default values for all of them, and easily and dynamically alter the allowed values.

Buttons: Power Apps also let’s you avoid the poor bookmark workarounds for creating multi-page and/or conditional input layouts. We can use multiple screens in our Power App, and dynamic show/hide properties to easily guide the user through a natural input process.

Communication with User and Power BI integration: The one place where Power Apps fall short. As mentioned, Power Apps only allow broadcasting notifications inside the app itself, which may fly under the radar for the end user, depending on how much report real-estate is dedicated to it.

In addition, Power Apps embedded in Power BI are very hard to consistently make look nice… Depending on the resolution of your Power BI report, the end-users screen resolution, and the actual size dimensions of your Power App, you may experience multiple design flaws ranging from the embedded app looking grainy/blurry to the app having thick, visible black borders around it inside the report. These things are possible to fix, but surprisingly hard to get consistently right.

Verdict: I would argue that Power Apps comes out on top.

Score: Power Apps 1, Translytical Task Flows 0

Development Experience

Developing Translytical Task Flows and Embedded Power Apps is not always smooth sailing. In this section, we’ll cover the pros and cons of working with each solution from a developer perspective.

Translytical Task Flows

Integration between Power BI Desktop & User Data Function editor: The link between Power BI Desktop and User Data Functions is… Not great.

I’ve had multiple occasions of having to wait for 5+ minutes (rebooting Power BI desktop didn’t solve the issue), before a change to a UDF became visible in the Power BI desktop setup. But I guess at least it automatically performs the visual refresh required for new data to show up – so points for that!

The testing experience leave quite a bit to be desired. You can test your User Data Function independently in Fabric with mock parameter inputs (something I learned way too late… I though you always had to trigger them from Power BI Desktop 🤦: Troubleshooting, debugging and Error Handling in User Data Functions / Translytical Task Flows – Downhill Data). But if you do try to test them from Power BI Desktop, your data model will automatically perform a local refresh every. single. time. Yes – even if your entire model is DirectQuery, it will do a metadata refresh.

I also find it slightly annoying that the Power BI pop-up will show “success” as long as the UDF was triggered correctly, even if whatever the UDF tried to do failed:

When that is said, if you configure your UDF correctly, you can pass error and logging information to the above “confirmation” pop up in Power BI, giving you great context for what went wrong.

Leveraging the Power BI engine: We can talk at lengths about the user input limitations obviously making things more difficult for the developer, but we already covered that above. Instead I’d like to highlight the excellent integration with Calculated Measures. The fact that they may be passed to any TTF parameter allow developers of TTFs to build quite complex calculations for picking up filter context or automatically passing model parameters to the TTF. This is awesome.

The User Data Function editor: The interface in which you configure your UDF is really just a Notebook. I found it decent to work with, but of course it is also pretty barebones. There is not a lot of help given to noobs like myself.

What I do find annoying, is that even in the editor itself, it can be difficult to troubleshoot any errors you make. Often you are left with pretty non-descript errors, with no hint as to what went wrong. It took me ages for example to figure out that the reason my Write-Back to Fabric Warehouse UDF was failing, was that I was not using proper Three-part naming convention (which you don’t need for SQL Databases in Fabric): Fabric Data Warehouse as write-back destination for Translytical Task Flows & User Data Functions – Downhill Data

Power Apps

Integration between Power BI & Development Environments: It is not only TTFs that require you to leave the familiar surroundings of Power BI Desktop. Power Apps require you to go into the Power Apps designer as well.

Power BI passes all the data added to the Field Well of the Power Apps visual to the Power App via the PowerBIIntegration connector, and this integration works okay-ish. It is easy to work with, and while you may initially be excited to see that any selection you make in Power BI Desktop/browser, will actually be reflected live in the Power Apps designer if it is open simultaneously in another tab, you will be equally disappointed when this seemingly-awesome link inevitably breaks after a few minutes.

It is also possible to auto-trigger the visual refresh in Power BI from the Power App, but contrary to TTFs, the developer need to explicitly call PowerBIIntegration.Refresh() for this to happen. And here we have a huge catch: This function is only available if the Power App was initially created from inside Power BI. Yes, that’s right. If you embed a Power App which you created from make.powerapps.com, this won’t work. It only works for apps created via the “Create New” button on the Power Apps embedded visual in side Power BI.

Leveraging the Power BI engine: Just like TTFs we can pass Calculated Measures and other fields from our semantic model to the Power App. Overall, this works mostly as well as for TTFs. However, developers will quickly be annoyed by the 1000 row limit limitation of PowerBIIntegration.Data().

The Power Apps designer: The Canvas designer is a low-code editor, with all its pros and cons. It is easier for new developers to get started, but difficult to accomplish complex API integrations. On the troubleshooting side of things however, the Power Apps monitor allows for easy monitoring of all signals going in and out of the app, including error descriptions and logs.

Verdict: Both tools are about equal, but TTFs have maybe a slightly better native Power BI integration, whereas Power Apps give you more “out of the box” in terms of troubleshooting and debugging. A point for each.

Score: Power Apps 2, Translytical Task Flows 1

Performance

While I haven’t done any true benchmarking here, I’d like to share a few observations anyway.

Translytical Task Flows

While TTFs have the benefit of being able to use the massive compute of your Fabric Capacity, they also have the drawback of having to wait for a session to start up. This means, that the first TTF operation from a Power BI report may take many seconds to start up (I’ve even heard some people claim minutes, not seconds, but I have not witnessed this). Once a session is live however, write-back operations take few seconds only, and you can do very complex operations in a very short amount of time with the UDF.

Power Apps

Power Apps have great performance out of the box… As long as you are only dealing with single rows of data. As soon as the number of rows manipulated balloons, performance degrades massively. You can remedy this by using Stored Procedures and JSON objects instead of the native data connectors, and while this works great, we are complicating our solution architecture somewhat.

Verdict: For single record manipulation, Power Apps wins. For bulk record manipulation TTFs are natively better, and Power Apps needs Stored Procedures to keep up. Another point for each.

Score: Power Apps 3, Translytical Task Flows 2

Solution Architecture & Cost

Translytical Task Flows

What can I say. Storage Item, User Data Function, Power BI Report. It’s simple and clean, and all within Fabric. Just buy a capacity, and get going. Awesome.

Cost wise this is obviously hard to isolate, but in my testing, the UDFs have not eaten any significant amount of capacity – it is more a question of your choice of backend item.

Power Apps

We substitute the User Data Function for a Canvas Power App, but that introduces an entire new platform, the Power Platform, to the mix. We now need to maintain licenses, security, monitoring and governance in two different platforms. Not great.

Cost wise, Power Apps Premium licenses are NOT cheap if this is the only use of it for your users. USD 20 pr. month is steep for a write-back solution.

Verdict: This is one of the big selling points for Translytical Task Flows. Clear winner. Point for TTFs.

Score: Power Apps 3, Translytical Task Flows 3

Final Verdict

Power Apps clearly wins on front-end functionality, User Input options and general End-User Experiece.

Translytical Task Flows clearly wins on solution architecture and cost.

Developer experience and performance is a bit of a toss-up, with your results varying heavily based on your specific circumstances.

My personal opinion? I welcome the Fabric Native solution with open arms, as the Power Platform licensing has often been a showstopper in previous projects, but if I have both at my disposal, I am likely to pick Power Apps over Translytical Task Flows in their current state (they’re also Generally Available, of course.).

Here’s to hoping we get better frontend options for TTFs soon!