Power Apps

How to Patch a SharePoint Yes/No Field in Power Apps

Use the correct Boolean and record shape when patching SharePoint Yes/No fields from Power Apps, with working create, edit, form and error-handling patterns.

Collab365 Team · Published 23 April 2026 · Refreshed 18 August 2026 · 7 min read

How to Patch a SharePoint Yes/No Field in Power Apps

The basic formula is short:

Patch(
    'Project requests',
    ThisItem,
    { Approved: true }
)

Use true for Yes and false for No. They are Boolean values, so they are not wrapped in quotation marks.

When the value comes from a control, pass the control's Boolean property:

Patch(
    'Project requests',
    galRequests.Selected,
    { Approved: togApproved.Checked }
)

The current modern Toggle exposes Checked. A classic Toggle commonly uses Value. Let Power Apps IntelliSense confirm the property for the control you actually inserted.

If that simple formula fails, the Yes/No value is often innocent. The usual problem is the base record, the column type, the control property, permissions or an unhandled connector error.

Understand the three parts of Patch

Microsoft defines Patch as a way to modify or create records.

An update has three essential parts:

Patch(
    DataSource,
    BaseRecord,
    ChangeRecord
)

For example:

Patch(
    'Project requests',
    galRequests.Selected,
    { Approved: togApproved.Checked }
)
  • 'Project requests' is the connected SharePoint list.
  • galRequests.Selected is the existing record to update.
  • { Approved: togApproved.Checked } is the change.

Microsoft's documentation makes an important point: for an update, the base record must be traceable to the data source. A record selected from a gallery bound to that list works. So does a record returned by LookUp.

Create a new item with a Yes/No value

Use Defaults when the app is creating a record:

Patch(
    'Project requests',
    Defaults('Project requests'),
    {
        Title: txtTitle.Value,
        Approved: togApproved.Checked
    }
)

Some classic text-input controls expose .Text instead of .Value. As with Toggle, select the control and use IntelliSense rather than copying a property from a different control generation.

Update the selected item

When the button sits inside a gallery row, ThisItem is usually the clearest base record:

Patch(
    'Project requests',
    ThisItem,
    { Approved: togApproved.Checked }
)

When the save button is outside the gallery, use the selected record:

Patch(
    'Project requests',
    galRequests.Selected,
    { Approved: togApproved.Checked }
)

If you only have an ID:

Patch(
    'Project requests',
    LookUp('Project requests', ID = varRequestId),
    { Approved: togApproved.Checked }
)

Do not replace LookUp with Filter here. LookUp returns one record. Filter returns a table, which is why this common formula fails:

// Wrong base-record shape for a single-record update
Patch(
    'Project requests',
    Filter('Project requests', ID = varRequestId),
    { Approved: true }
)

Save a literal Yes or No

You do not need a Toggle when the action itself determines the value.

Approve:

Patch(
    'Project requests',
    ThisItem,
    { Approved: true }
)

Revoke approval:

Patch(
    'Project requests',
    ThisItem,
    { Approved: false }
)

This is different from sending the text strings "Yes", "No", "true" or "false". Those are Text values. Microsoft lists Boolean as a separate Power Fx data type.

Add honest success and failure handling

A green notification should appear only after the connector accepts the update.

IfError(
    Patch(
        'Project requests',
        galRequests.Selected,
        { Approved: togApproved.Checked }
    );
    Notify("Saved", NotificationType.Success),
    Notify(
        "Could not save: " & FirstError.Message,
        NotificationType.Error
    )
)

The semicolon chains the successful Patch and success notification as one branch. The error branch also returns the result of Notify, keeping the possible result types compatible.

Microsoft recommends IfError for handling Patch failures. During development, FirstError.Message is useful. In a public app, give the user a clear message and log the detailed diagnostic somewhere appropriate; raw connector text can contain internal names or URLs.

Do not reset the form, navigate away or show “Saved” before the Patch succeeds.

Keep the returned record

Patch returns the record it created or changed. Capture it when later logic needs the server-assigned ID or final values:

IfError(
    Set(
        varSavedRequest,
        Patch(
            'Project requests',
            Defaults('Project requests'),
            {
                Title: txtTitle.Value,
                Approved: togApproved.Checked
            }
        )
    );
    Notify(
        "Saved request " & Text(varSavedRequest.ID),
        NotificationType.Success
    ),
    Notify("The request was not saved", NotificationType.Error)
)

This is usually better than immediately running a broad Refresh and searching for the row you just created.

When SubmitForm is the better answer

If the screen is a normal edit form, do not use Patch merely because it looks more advanced.

Unlock the Yes/No data card only when necessary, set the card's Update property to the Toggle's Boolean property, then use:

SubmitForm(frmRequest)

Use the form's OnSuccess and OnFailure properties for navigation and messages.

Choose Patch when you are saving a partial record, combining values outside a form, creating several related records or implementing a custom interaction. Choose SubmitForm when the form already owns validation, required fields and the complete save path.

SharePoint Yes/No versus Dataverse Yes/No

Both are Boolean concepts in Power Apps, but do not assume every field labelled “status”, “approved” or “active” is a Yes/No field.

Check the data source:

  • SharePoint Yes/No column → Boolean.
  • Dataverse Yes/No column (formerly called Two Options) → Boolean behaviour in the app.
  • SharePoint Choice column with choices “Yes” and “No” → a Choice value, not a Boolean.
  • Text column containing “Yes” or “No” → Text.

Changing the Power Apps formula cannot repair a column created with the wrong type. Confirm the schema before adding conversions.

Common errors and the real fixes

Invalid argument type: Table

Your base-record expression probably returns a table.

Use:

LookUp('Project requests', ID = varRequestId)

instead of:

Filter('Project requests', ID = varRequestId)

Expected Boolean but found Text

Pass true, false or the control's Boolean property. Remove Text(...), quotation marks and labels such as "Yes".

The formula is valid but nothing changes

Check:

  1. The app is connected to the expected list and environment.
  2. The base record is the row you think it is.
  3. The user has permission to edit that item.
  4. The column is actually a Yes/No column.
  5. IfError is capturing the connector response.
  6. Another flow, rule or app is not changing the value afterwards.

Use Live monitor during a test run to inspect the connector call instead of guessing.

The Toggle shows the wrong existing value

The save formula may be correct while the control's default is wrong.

For an edit screen, set the modern Toggle's checked/default input to the current record's Boolean field, for example:

galRequests.Selected.Approved

In a form, use the value supplied by the card/Parent.Default pattern generated for that control. Test both new and edit modes.

UpdateIf works for a few rows but misses others

UpdateIf is useful for conditional updates, but large-data behaviour depends on the connector and delegation. Microsoft documents Update and UpdateIf separately from Patch.

Do not publish a fixed “delegates up to 2,000 rows” rule. Watch for delegation warnings and test above the app's data-row limit. For a large or business-critical bulk change, use a server-side governed process with batching, audit and recovery.

A five-minute test

Test with an ordinary user, not only the maker:

  1. Open a known item where the field is No.
  2. Change the Toggle to Yes and save.
  3. Confirm the success message appears only after the connector call.
  4. Reopen the item from SharePoint and verify Yes.
  5. Change it back to No and repeat.
  6. Remove the user's edit permission temporarily in a test list and confirm the app shows a failure, not a false success.
  7. Test a blank/new record and an existing record separately.

That proves the complete path: control → Boolean → record → connector → SharePoint → reload.

For more practical formulas and production-safe app patterns, join the Power Apps Builders Space.

Frequently asked questions

What value should I Patch into a SharePoint Yes/No column?

Use the Boolean value true for Yes or false for No. Do not wrap the value in quotation marks.

Which Toggle property should I use?

The current modern Toggle uses Checked; a classic Toggle commonly uses Value. Use IntelliSense to confirm the property on the control in your app.

Why does Patch say it expected a record but found a table?

The base-record expression probably uses Filter, which returns a table. Use ThisItem, a selected gallery record or LookUp for a single-record update.

Should I use Patch or SubmitForm for a Yes/No field?

Use SubmitForm when a form owns the complete record and validation. Use Patch for a targeted/custom save or when creating and updating records outside a form.

Can I bulk-update a Yes/No field with UpdateIf?

Yes, but connector delegation and the app data-row limit matter. Check warnings and test the real data volume; use a governed server-side process for large or high-risk bulk updates.