Power Apps: Refresh() Is Killing Your App Performance - an Alternative Method, from Paul O'Flaherty

TL;DR: Refresh() reloads the entire data source. After your own Patch() you don’t need that, because Patch() returns the record it just wrote. Put that record into a variable or into your collection and keep Refresh() for the moments when other users or processes changed the data.

Calling Refresh() after every edit is one of the most common Power Apps performance mistakes. Paul O’Flaherty explains why, and what to do instead.

💡 Challenge

A typical save button looks like this:

Patch(Orders, ThisItem, { Status: "Done" });
Refresh(Orders)

Every click writes one record and then reloads the whole Orders source from the server. The user waits for a round trip that brings back data the app already knows, and the wait grows with the size of the list.

✅ Solution

Use the return value of Patch(). Patch returns the record that you modified or created, including values the data source generated itself, such as the ID of a new record. That record is everything the screen needs.

🔧 How It’s Done

1. Drop the Refresh after your own Patch.

🔸 Keep the result of the write in a variable, for example for a detail screen:

UpdateContext({ locCurrentItem: Patch(Orders, ThisItem, { Status: "Done" }) })

🔸 Bind the detail controls to locCurrentItem. They show the saved values right after the write.

2. Update a cached collection with the returned record.

🔸 If your gallery shows a collection (colOrders) instead of the data source, write the saved record into it:

With(
    { saved: Patch(Orders, ThisItem, { Status: "Done" }) },
    Patch(colOrders, LookUp(colOrders, ID = saved.ID), saved)
)

🔸 The collection now holds exactly what the server stored, without reloading anything.

3. Refresh only on demand.

🔸 Give the user a refresh icon with OnSelect: Refresh(Orders) for the moments when they want to see changes from colleagues.

🔸 Call Refresh() after a background flow has changed records, or when Patch() fails with Conflicts exist with changes on the server.

4. Check the effect in Live monitor.

🔸 In Studio, select Advanced tools > Open live monitor and click the save button with and without Refresh(). Without it, you only see the write request; with it, a second request reloads the data source.

🎉 Result

The save button writes one record and the screen updates immediately. The app only reloads data when it actually needs data it doesn’t have.

🌟 Key Advantages

🔸 Fewer round trips: one write instead of write plus full reload.

🔸 Correct values: the returned record includes server-generated columns such as the ID.

🔸 Scales with the data: the cost of a save no longer grows with the size of the list.

🎥 Video Tutorial

🛠️ FAQ

1. Why is Refresh() bad for Power Apps performance?

Refresh() retrieves a fresh copy of the whole data source, not just the record that changed. After your own edit that is a full reload for information the app already has.

2. What should I do instead of Refresh() after editing one record?

Use the record that Patch() returns. Store it in a variable for the detail screen, or write it into your collection with a second Patch, instead of reloading the whole data source.

3. When is Refresh() still the right call?

When other users or processes changed the data, for example a flow that updates records in the background, or after the error Conflicts exist with changes on the server. Trigger it on demand, not after every save.

🔗 Related Tips

🔸 #PowerPlatformTip 38: ‘Data Refresh’ - the same selective-refresh idea, using a Boolean variable to reload only a gallery.

🔸 #PowerPlatformTip 81: ‘Fast Datasource Updates’ - more performance patterns for large data sets with ClearCollect, UpdateIf and Patch.

---

You can see this video here on my blog because I have rated this video with 5 stars in my YouTube video library. This video was automatically posted using PowerAutomate.