Skip to content

Conflicts exist with changes on the server, please reload. Server Response: ETAG mismatch

The PowerApp was working just fine… until it wasn’t. Customers were reporting that they were getting errors in the form of a red bar at the top of the screen. The problem appears to be trying to do two updates to a record too quickly.

The Scenario

The scenario we were hitting was one where we had a form that included a set of fields from a record – but not all of them. In this case, I needed to update some flags based on values and what had changed. I didn’t want these controls on the form, because the user didn’t need to see them and certainly shouldn’t change them.

Think about it this way: I needed to set a “dirty bit” on the record to indicate that something important had changed, so another process could pick up the item and take some actions. You don’t want a user seeing that the record is “dirty.” While it’s standard IT parlance, it doesn’t give customer a warm and fuzzy feeling.

In this scenario, I had a form bound to a context variable called Order, which came from the Orders collection/data set. So, when I went to update the form and the dirty bit, I had code that was effectively:

Patch(Orders, Order, {IsDirty : true});


The problem is that, when I did this, the SubmitForm() would fail with the ETAG mismatch. Swapping the order of the operations didn’t help; in that case, the patch would fail.

The Solution

The solution turned out to be something I already had written for transitions between screens. I looked up the order and reloaded it in the context variable:

UpdateContext({Order: LookUp(Orders, OrderNumber = Order[@OrderNumber])})

This forced the reload of the context variable. Obviously, in this case, the primary key of the dataset is the OrderNumber field, so I can use that to force a reload of the item. One last swap was to move the patch after the SubmitForm(), so I didn’t clear the form when I reloaded the context variable. I ended up with:


UpdateContext({Order: LookUp(Orders, OrderNumber = Order[@OrderNumber])})

Patch(Orders, Order, {IsDirty : true});

That sequence works, because I effectively force the context variable to be reloaded right before I make the patch.

No comment yet, add your voice below!

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share this: