The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.
Recently, I was asked to integrate a Power App form into a Power BI report to enable write-back functionality for end users. While working on this task, I encountered two interesting challenges. In this blog, I’ll walk you through what those challenges were and how I worked around them.
A company maintains insurance records for its global assets using an Excel workbook. These include both insurance premium payments and claims filed due to business disruptions or calamities. The company wanted to:
We created:
Challenge 1: Triggering the Right Form Based on Report Page
To test integration, I designed a Power App with five screens:
Then I embedded this app in both report pages using the Power Apps visual.
The problem: Regardless of the Power BI report page, the embedded app always loaded the landing page. There was no native way to make the app load a specific form based on which report page it was embedded in.
Finding: After some research, I learned Power BI does not support deep linking to different app screens via the visual itself. This was my first challenge.
If you’ve ever used the Power Apps visual in Power BI, you’ve likely seen this odd behavior:
This may seem harmless, but stakeholders were unhappy with the poor user experience. I reached out to the Power BI community, and learned this is a known issue with no current fix.
If you observe the above gif, you will observe both the challenges I explained above. Both the Premiums report page and in the claims tab, the default page is the landing page and the app rendering is showing “Lets get started” page for a fraction of second.
Let me be clear I’m not an expert in Power Apps. But here’s how I managed to solve both problems with a simple workaround:
Step 1: Add index columns
I added an index column to both the premiums and claims tables in Power BI. This unique ID helps identify individual records.
Step 2: Use DAX to generate app URLs
I removed the Power Apps visual from both report pages and replaced it with a DAX measure that generates a clickable URL in a table visual.
Power Apps supports URL parameters which means we can pass values (like IDs) directly to the app.
Example:
ClaimsAppURL = "https://apps.powerapps.com/play/e/<EnvironmentId>/a/<AppId>?PremiumsItemID=&ClaimsItemID=" & SELECTEDVALUE('RISK Management Claims'[ID] )
PremiumsAppURL = "https://apps.powerapps.com/play/e/<EnvironmentId>/a/<AppId>?PremiumsItemID=" & SELECTEDVALUE('RISK Management'[ID]) & "&ClaimsItemID=" & ""
Step 3: Read Parameters in Power App
Inside the app, I created two global variables:
Set(PremiumsItemID, Param("PremiumsItemID"));
Set(ClaimsItemID, Param("ClaimsItemID"));
These capture the values passed via the URL.
Step 4: Add a Loading Screen
I created a “Loading Screen” in Power Apps with:
Step 5: Navigate Automatically Based on Passed Parameter
For the timer’s OnTimerEnd property, I added the following logic:
If(
ClaimsItemID <> "" And PremiumsItemID<>"",
Navigate('StartScreen'),
If(
ClaimsItemID <> "",
Navigate('Edit Claims Record'),
Navigate('Edit Premiums Record')
)
)
When the app loads:
Benefits of This Approach
✅ One Power App handles multiple forms
✅ App opens the right screen based on data selected in Power BI
✅ No rendering delay or confusing “Let’s get started” prompt
✅ Improved UX and performance
I understand this workaround doesn’t strictly follow the idea of embedded write-back using the Power Apps visual. But given the limitations I encountered, this was a practical and scalable solution.
With this approach, we achieved:
If you’ve encountered similar issues or have other solutions, I’d love to hear them drop your thoughts in the comments.
Thanks for reading!
Happy building
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.