Fix "The requested operation is invalid" when Power Apps Patch fails

The banner says "Network error when using Patch function: The requested operation is invalid", and nothing else. It comes up again and again on Microsoft's forums, and it's confusing because the network is usually fine. Power Apps uses this one wording for several different failures. The data source refused the save and the banner doesn't say why, so the fix starts with finding that reason.

Read the real reason

Microsoft's Patch reference says this kind of failure can come from connectivity, permissions or data conflicts, and recommends catching it with IfError. Show the message instead of the generic banner:

IfError(
    Patch(Requests, Defaults(Requests), { Title: txtTitle.Text, Owner: cmbOwner.Selected }),
    Notify("Save failed: " & FirstError.Message, NotificationType.Error)
)

If the message is still vague, open Live monitor (in Studio, Advanced tools > Open live monitor), play the app, save once, and select the failed patch event for your list. Its details include the HTTP request and the response, which shows what SharePoint or Dataverse actually replied and usually names the column.

The error also carries a kind. Microsoft's list of error kinds explains it: 2 is a missing required value, 8 is a constraint that was violated (such as a duplicate in a unique column), 10 is a read-only column, and 11 is a failed validation check.

The usual causes

A column that must be unique

In SharePoint, a column can be set to Enforce unique values (open the list's Settings, select the column, and look under More options). A second item with the same value is refused, and Microsoft documents the comparison as case-insensitive, so "INV-100" and "inv-100" count as the same value. It's the cause suggested in the most-upvoted Microsoft Q&A answer on this exact error.

Check first, and give a clear message instead of the banner:

If(
    IsBlank(LookUp(Requests, InvoiceNumber = txtInvoice.Text)),
    Patch(Requests, Defaults(Requests), { Title: txtTitle.Text, InvoiceNumber: txtInvoice.Text }),
    Notify("Invoice " & txtInvoice.Text & " is already in the list.", NotificationType.Warning)
)

The = test on a text column delegates to SharePoint, so the check works on big lists.

A Person value without an email

In a solved Power Platform Community thread, a multi-select Person column failed with this error (kind 8) because the people's records had lost their Mail value: the records were built from Office365Users results and re-used after the first save. SharePoint identifies a person by the Claims and Email in the record, so a blank email can't be saved.

Build each person once, with the email filled in, and keep the result in a variable so a second Patch uses the same records:

Set(
    varOwners,
    ForAll(
        Filter(cmbOwners.SelectedItems, !IsBlank(Mail)),
        {
            Claims: "i:0#.f|membership|" & Lower(Mail),
            DisplayName: DisplayName,
            Email: Mail,
            Department: "",
            JobTitle: "",
            Picture: ""
        }
    )
);
Patch(Requests, galRequests.Selected, { Owners: varOwners })

Accounts without a mailbox (some guests and service accounts) have no Mail, which is why the Filter drops them. Our guide to patching Person, Choice and Lookup columns has the single-person and combo-box versions.

Required and validated columns

SubmitForm fills in what the form shows, so a required column with a default can pass there and fail in your Patch. When you create an item with Defaults(...), include every required column, Title included. If the list or column has a validation formula (list Settings > Validation settings, or a column's Column validation), the value must satisfy it; show the rule's message to the user before saving rather than after.

If you renamed or removed columns in the list after adding it to the app, refresh the data source in Studio (in the Data pane, select ... next to the list and choose Refresh), so the app writes to the columns that exist now.

On SQL Server: check the primary key

Microsoft's SQL Server documentation is direct: the connector assumes tables have a primary key, and a table without one is read-only in Power Apps. Add a key (an identity column is the simplest) and refresh the data source. Tables with triggers need a stored procedure for writes instead of a direct Patch or SubmitForm.

Still stuck? Narrow it down

Sources

• Patch function: common errors — Microsoft Learn
• Error handling: ErrorKind values — Microsoft Learn
• Debugging canvas apps with Live monitor — Microsoft Learn
• Access data in SQL Server: primary keys and triggers — Microsoft Learn
• Enforcing uniqueness in column values (SharePoint) — Microsoft Learn
• Power Apps: network error while using Patch — Microsoft Q&A
• Network error when using the Patch function (solved) — Power Platform Community