Power Apps Patch network errors: troubleshoot SharePoint saves

Treat the network message as a symptom

“Network error when using Patch” can have several causes: a connection problem, missing permissions, a rejected field value or an invalid base record. Record what failed before changing the app.

In an approved development copy, try one save with one made-up record. Note the time, record ID, user's role, full error category and fields changed. Keep confidential details out of shared screenshots. Live monitor can help inspect requests and failures.

The Errors function can return the record, column, message and error kind after a data operation. Read or save those details straight away; another operation on the same source can clear them. Do this before Refresh or another Patch. Keep technical messages with sensitive details off normal user screens.

Check the source, record and field separately

See Microsoft's guidance on sharing app resources and SharePoint field types. Do not grant extra permissions just to hide an error. If the list's columns changed, record the error first. Then refresh the app's data-source definition and check its field formulas in a development copy.

Try a small update that handles failure

This example updates an existing row in a fictional SharePoint list named Delivery Work. It assumes galWork is a gallery of records from that exact list, txtWorkTitle is a classic text input, and Title is the standard text column. The selected item must already meet the list's other rules. This example updates a row; it does not create rows or write complex fields.

Set the save button's OnSelect to:

If(
    IsBlank(galWork.Selected.ID),
    Notify("Select a work item.", NotificationType.Warning),
    IsBlank(Trim(txtWorkTitle.Text)),
    Notify("Enter a title.", NotificationType.Warning),
    If(
        IsError(
            Patch(
                'Delivery Work',
                galWork.Selected,
                {Title: Trim(txtWorkTitle.Text)}
            )
        ),
        Notify("Update failed. Keep your edits and contact the app owner.", NotificationType.Error),
        Notify("Update saved.", NotificationType.Success)
    )
)

The first two checks require a selected record and a nonempty title. IsError checks the Patch result so a failed save does not show a success message. Keep the user's input after failure. Do not add a success message, Reset or navigation after the formula that runs regardless of the result.

Microsoft's Patch reference explains why the record being updated must come from the source. Creating a record is a different operation, normally using Defaults from the same data source. Replacing the selected record with Defaults can turn an intended update into a create.

The error-handling reference covers IsError and IfError. Error handling must be enabled for these functions to work correctly; check older apps where it may have been disabled. This example uses English-locale separators; Power Fx separators can differ with authoring locale.

Check the saved result, then add the other fields

After a successful response, reopen the same item by ID in the source and check the new title. The success message reports the formula's result; it does not mean a later flow or report refresh has finished. Add the other fields one at a time and repeat the check.

If the response was interrupted, check the source before trying again. The first save may already have worked. Retrying could create a duplicate record or repeat an action.

If the screen already uses an Edit form, consider its SubmitForm process rather than replacing working field formulas with a large Patch formula. Put navigation after a successful save in the form's OnSuccess and handle failures in OnFailure. See Microsoft's app error-handling guidance.

Another example: capture the save error before refreshing

In an approved development copy with made-up rows, save the data-source error table as soon as Patch fails. In the earlier formula, replace only the failure Notify expression with these actions:

ClearCollect(colSaveErrors, Errors('Delivery Work'));
Notify("Update failed. Keep your edits.", NotificationType.Error)

Keep the checks for a selected record and a nonblank title. After a successful save, clear any earlier error details before showing success:

Clear(colSaveErrors);
Notify("Update saved.", NotificationType.Success)

On the app owner's development screen, a temporary classic Label can show the saved error details. Set its Text to:

Concat(
    colSaveErrors,
    Coalesce(Column, "(record)") & ": " & Message,
    Char(10)
)

Expected check: when the connector supplies error details, the collection keeps them before another write or Refresh can clear them from the source. Some connectors may not return details for a specific field. An empty collection does not prove the save worked; the IsError branch still reports failure.

Test with an approved read-only test user or a deliberate validation failure on a sample record, then with a valid update. The valid update should clear the earlier diagnostic collection. Errors may include sensitive values, so remove this development label and raw messages from ordinary-user screens. Microsoft documents the Errors table and its lifetime. This example saves error details; you still need to fix any permission or data-type problem.

Another example: use an Edit form to handle the save

If the app already uses a generated form with complex field cards, keeping SubmitForm may be easier to maintain. In a development copy, use an Edit form named frmWork with DataSource 'Delivery Work', Item galWork.Selected, and DefaultMode FormMode.Edit. Select an existing sample row and include its Title card.

Save button OnSelect:

SubmitForm(frmWork)

Form OnSuccess:

Notify("Update saved.", NotificationType.Success)

Form OnFailure:

Notify("Update failed. Keep your edits and contact the app owner.", NotificationType.Error)

Expected: a successful save shows the success message. A rejected save runs OnFailure and leaves the form ready to correct. A missing required field may stop the save before a server request. Test that case and a save rejected by the source. If the app should leave the screen after saving, put that action in OnSuccess, not immediately after SubmitForm on the button.

Microsoft's form function reference explains how this works. See the defaults and reset guide before adding a Cancel or New button. Resetting a form and saving it are separate actions; a failed save should not silently discard the user's work.

Test success and failure as an ordinary app user

Use approved test accounts and sample items. These are checks for you to run; we did not run them for this article.

• Valid edit: select an existing sample item, change its title, save and confirm the same ID contains the change.
• No selection or blank title: the guard message appears and no update is attempted.
• Not enough access: a test user with read-only access sees a failure, keeps their input and gets no false success message.
• Rejected field or stale record: record the actual error, keep the edits and follow the agreed recovery steps.
• Two users or an interrupted response: inspect the final record and decide how to handle conflicts or uncertain completion for this connector.

For the next person maintaining the app, note the source, field types, expected access, save formula, error details and checks still needed. A Power Apps project can cover those app-specific decisions.

Technical sources checked September 25, 2026. This original example uses made-up data and was checked against Microsoft documentation. We did not test it in a Power Apps environment, and it is not a client result.