Fixed: "Network Error When Using Patch Function: ETAG Mismatch" in Power Apps

Patch fails with Network error when using Patch function: [YourList] ETAG mismatch. It isn't a network problem. The SharePoint item changed after your app read it, so SharePoint refused to overwrite the newer version. Catch it with IfError, tell the person what happened, and reload the item.

The Error

In the Career Development Plan app, an employee opens their response to a competency. While the screen is open, their manager approves that response. The employee then edits the text and selects Update response, which runs a Patch on the record the screen loaded earlier (How to Create or Update a SharePoint List Item with Patch).

With an error handler that showed the raw message, this banner appeared:

Error message

Network error when using Patch function: [CompetencyResponses] ETAG mismatch. clientRequestId: 00000000-0000-0000-0000-000000000000 serviceRequestId: 00000000-0000-0000-0000-000000000000

The list name in brackets is yours, and the two request IDs change every time.

What Happened

SharePoint gives every list item a version tag, an ETag. An update can say which version it expects, and if the item has moved on, SharePoint refuses it (Working with lists and list items with REST). That's the ETAG mismatch: the app's copy of the item was older than the one in SharePoint.

Nothing was overwritten. After the failed update, the item was still Approved, with the manager's version intact. That's the protection you want: without it, the employee's edit would have quietly undone the approval.

In Power Fx, this error's Kind is ErrorKind.Conflict. Microsoft describes it as: "Another change was made to the same record, resulting in a change conflict" (Errors function). The Patch reference calls this case Conflicts exist with changes on the server; the SharePoint connector's own text is the one above.

The Fix: Catch the Conflict

You can't stop two people changing the same item. You can make the app say what happened instead of showing a technical message. Wrap the Patch in IfError and check FirstError.Kind (How to Handle Errors in Power Apps with IfError):

btnSendRS → OnSelect (error handling part)

IfError(
    Patch(...),
    Notify(
        If(
            FirstError.Kind = ErrorKind.Conflict,
            "This response changed while you were editing it. Go back, open it again and make your change.",
            "Your response wasn't sent. " & FirstError.Message
        ),
        NotificationType.Error
    ),
    Notify("Your response was sent to your manager.", NotificationType.Success)
)

The same conflict then shows a message people understand:

Then Reload the Item

The app's copy is out of date, so the next Patch would fail the same way. Read the item again before the person tries once more. In the example, opening the screen refreshes the list and loads the item with LookUp, so going back and opening it again gets the current version (How to Add a Refresh Button to a Screen). In that case it opened as Approved and read-only, which was right. Microsoft's alternative is to call Refresh on the data source and try again (Refresh function).

Common Mistakes

Mistake	What happens	Do this instead
Showing FirstError.Message as it is	People see ETAG mismatch and two IDs	Check FirstError.Kind = ErrorKind.Conflict and explain
Retrying the same Patch	It fails again: the record is still old	Reload the item first
Treating it as a network problem	Time wasted on connections	Look for another change to the same item

Troubleshooting

Symptom	Likely cause	Fix
It happens with only one person using the app	Something else changed the item, such as an edit in SharePoint or another browser tab	Reload the item before saving

FAQ

Did my change get saved?

No. The update was refused, and the item kept the other person's version. Reload the item and make your change again.

Can I make Patch overwrite anyway?

The SharePoint REST API can force an overwrite, but that's exactly the lost update this check prevents. In an approval process, the newer change usually matters more.

Conclusion

ETAG mismatch means someone changed the SharePoint item after your app read it. SharePoint refused the stale update, and FirstError.Kind is ErrorKind.Conflict. Show a clear message with IfError, and reload the item before trying again.

Additional Resources

• Patch function: common errors
• Errors function: ErrorKind values
• Working with lists and list items with REST: ETags

Related

• How to Show a Notification in Power Apps with Notify
• How to Find a Record in Power Apps with LookUp