PowerApps Patch 101: Patching SharePoint Columns for Beginners

Power Apps’ Patch function is a powerful tool that lets you create or update records in a data source through formulas [learn.microsoft.com]. In a SharePoint context, Patch enables you to save form inputs or custom values back to a SharePoint list without using the standard form submit. This is useful for building dynamic apps with custom logic (e.g. updating multiple lists at once, or partially updating a record) [learn.microsoft.com]. We typically use SharePoint as the data source for such examples because it’s readily available in most Microsoft 365 plans, whereas Dataverse (the premium alternative) requires additional licensing [powerapps911.com]. In short, SharePoint lists are a convenient starting point for new app makers, and Patch gives you flexibility beyond the built-in form controls.

In this beginner-friendly guide, we’ll introduce the Patch function syntax using modern Power Fx, then walk through patching various SharePoint column types. We’ll cover Date, Currency, Lookup, Choice (single and multi-select), Person (single and multi-select), Hyperlink, Yes/No, and Managed Metadata (single and multi-select) columns. For each, we’ll describe the SharePoint column setup, show the Patch formula in Power Fx, and note common pitfalls or errors. By the end, you should feel more confident using Patch to build dynamic Power Apps that work with SharePoint data. Let’s get started!

Patch Function Basics (Syntax and Usage)

In Power Fx (the formula language for Power Apps), the Patch function has a simple pattern:

powerfx

Patch(DataSource, BaseRecord, { Field1: NewValue1, Field2: NewValue2, ... })

DataSource is your connected data source (e.g. a SharePoint list).
BaseRecord specifies which record to modify. For updating an existing item, you provide a reference to that item (such as a record or an expression that finds it). For creating a new item, you use Defaults(DataSource) as the base record [rezadorrani.com].
The last parameter is one or more ChangeRecord objects: essentially a {Field: Value} mapping that defines which columns to update and their new values [rezadorrani.com]. Any fields not mentioned remain unchanged.

Examples:

Create a new record: Patch(Projects, Defaults(Projects), { Title: "New Project", Status: "Active" }) – this creates a new item in the Projects list with Title and Status set, leaving other fields at their defaults.
Update an existing record: Patch(Projects, LookUp(Projects, ID=5), { Status: "Completed" }) – this finds the item with ID 5 in Projects and updates its Status to “Completed”. You could also reference a record from a Gallery’s selection (e.g. Gallery1.Selected) in place of the LookUp for convenience.

Why use Patch? Patch is best when you need fine control or to update multiple sources at once. For simple forms, using an Edit form and SubmitForm is easier; but Patch shines for custom behaviors (e.g. saving different data on different button clicks, or updating part of a record without affecting the rest [learn.microsoft.com]). Patch also allows writing to multiple records at once (advanced scenario) and can be combined with formulas like ForAll to batch-update tables. In this post, we focus on single-record patches for various field types.

A note on OData types: Some SharePoint columns (like People, Choices, Lookups, etc.) are complex types. Under the hood, Patch needs special record structures (including an @odata.type and specific subfields) to update these [powerappsguide.com]. Manually constructing these can be intimidating for beginners. The good news is that if you use controls bound to the SharePoint data (via the Choices function), Power Apps will handle those structures for you. We’ll demonstrate both the manual format and the easier method using controls for complex columns.

With the basics covered, let’s dive into patching each type of SharePoint column.

Patching a Date Column

SharePoint Column Setup: A Date column in SharePoint can be configured as “Date Only” or “Date & Time”. For example, a “DueDate” field might store just a date (no time). Power Apps will treat SharePoint dates as DateTime values. If the column is Date Only, the time portion is ignored (or set to midnight). It’s important to pass a proper date value to Patch – either a Date/Time value or something that can be interpreted as one.

Patch Formula (Date Example): Suppose we want to patch the DueDate field of an existing item to December 25, 2025. We can do either of the following:

powerfx

// Using a literal Date value:
Patch(Tasks, LookUp(Tasks, ID=1),
      { DueDate: Date(2025, 12, 25) } );

// Using a Date Picker control value:
Patch(Tasks, LookUp(Tasks, ID=1),
      { DueDate: DatePicker1.SelectedDate } );

Both approaches will set the “DueDate” of item ID 1 in the Tasks list to 25-Dec-2025 [matthewdevaney.commatthewdevaney.com]. If the SharePoint column includes time, you could use a DateTime value (e.g. Now() for current date & time, or DateAdd(DatePicker1.SelectedDate, TimePicker1.SelectedTime) if time is taken separately).

Notes & Pitfalls:

Ensure the value patched is recognized as a Date/Time. If you’re taking input from a text box, convert it using DateValue or DateTimeValue with an appropriate format. For example, DateValue("12/25/2025") or using ISO format "2025-12-25" to avoid locale confusion.
If you omit the time for a DateTime column, SharePoint will default it to midnight UTC. Be mindful of time zone differences; using UTC or adjusting with TimeZoneOffset might be necessary for exact times, but for beginners it’s usually not an issue if using Date pickers (they provide Date values without time, which SharePoint stores relative to midnight).
Common error: Patching a date as text (without conversion) will result in a type mismatch error. Always provide a Date type. If you see a “network error” on Patch, check that your data types match the SharePoint column types.

Patching a Currency Column

SharePoint Column Setup: A Currency column in SharePoint is essentially a number field with currency formatting. It has a specific currency locale (e.g. USD, EUR) and decimal precision configured. Let’s say we have a “Budget” field of type Currency in a Projects list.

Patch Formula (Currency Example): Patching a currency is just like patching a Number – provide a numeric value:

powerfx

// If using a Text Input for amount, convert text to number
Patch(Projects, Defaults(Projects),
      { Budget: Value(txtAmount.Text) } );

In this example, a new Project record is created with its Budget set to the numeric value of txtAmount.Text. If you have the number already (say from a slider or calculation), you can use it directly (e.g. {Budget: 50000} for 50,000) [powerapps911.com]. SharePoint will format it with the currency symbol (configured in the column settings) once patched.

Notes & Pitfalls:

Data type: The value must be a number (decimal or integer). If you have a text input, wrap it with the Value() function as shown above [powerapps911.com]. Forgetting to do so is a common mistake – Patch will error if you try to send a text to a numeric column.
Currency format: You cannot change the currency type (e.g. from USD to EUR) via Patch; that’s a list setting. Patch only sets the numeric amount. The SharePoint list will automatically display it with the defined currency.
Large values: Currency in SharePoint has a fixed 4 decimal precision. Very large numbers are generally fine (up to around 10^13 in value). If you attempt an out-of-range value, SharePoint will reject it – but that’s rare.

Patching a Lookup Column

SharePoint Column Setup: A Lookup column links to an item in another list. For example, you might have an “Employee” lookup in a Tasks list that points to an Employees list (perhaps storing the Employee’s Name as the display). SharePoint stores lookup values as a combination of an item ID and a display text (the primary column of the target list, e.g. Title). In Power Apps, a lookup field is represented as a record with at least an Id field (the linked item’s ID) and a Value field (the display text) [rezadorrani.com].

Patch Formula (Lookup Example): To patch a lookup, you need to provide an object with the target item’s Id (and optionally its Value). For example, to set a Task’s Employee lookup to point to the Employee with ID 7:

powerfx

Patch(Tasks, Defaults(Tasks), 
      { Employee: { Id: 7, Value: "John Doe" } } );

This creates a new Task item with its Employee field referencing the item ID 7 from the Employees list [rezadorrani.com]. Alternatively, if you have the record of the employee (say from a dropdown or a lookup formula), you can provide that. A more dynamic approach is to use a dropdown bound to the lookup Choices and use its selection:

powerfx

// Assume drpEmployee is a Dropdown with Items = Choices(Tasks.Employee)
Patch(Tasks, Defaults(Tasks),
      { Employee: drpEmployee.Selected } );

By setting the Items property to Choices(Tasks.Employee), Power Apps knows to populate the dropdown with actual records of the related Employees. drpEmployee.Selected will already be a record with the proper Id/Value shape, so you don’t have to manually build it [powerapps911.compowerapps911.com].

Notes & Pitfalls:

Id is key: The Id must correspond to a valid item in the lookup’s source list. If you provide an incorrect Id, Patch will fail (and no new item will be created in the target; the lookup won’t accept arbitrary values).
Value field: Including the Value (the text) is recommended, though SharePoint primarily uses the Id. In many cases, you can actually patch just {Id:7} for the lookup and it will resolve, but providing Value (even an empty string) can avoid ambiguity [powerappsguide.com]. Power Apps often includes an @odata.type automatically as well (e.g. "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference" behind the scenes) [powerappsguide.com], but if you use the Choices() method, you don’t have to worry about that.
Clearing a lookup: If you need to blank out a lookup (and the column allows no value), one trick is to patch an Id of -1 and Value of empty string [powerappsguide.com]. This is a special SharePoint convention to clear lookup fields. For example: { Employee: { Id: -1, Value: "" } } would clear the Employee field.
Multiple lookups: If your lookup column is configured to allow multiple values, the Patch needs a table of lookup records. The structure is similar but wrapped in a Table(). For instance, to patch two lookup values: { MultiLookupField: Table( {Id:1, Value:"Item1"}, {Id:2, Value:"Item2"} ) } [rezadorrani.com]. Using a multi-select ComboBox with Items = Choices(List.MultiLookupField) and SelectedItems in the Patch is an easier way in that scenario (Power Apps will supply the table of selected records automatically).

Patching a Choice Column (Single-Select)

SharePoint Column Setup: A Choice column (single-select) provides a dropdown of fixed options (e.g. Status could be a choice of “Open, In Progress, Closed”). In Power Apps, a single-select choice field is treated similarly to a lookup behind the scenes – it has a Value field containing the selected option text [rezadorrani.com]. (The connector also treats it as a “reference” type, but you typically just provide the value.)

Patch Formula (Single Choice Example): To patch a single-choice field, provide a record with a Value. For example, if Status is a choice field:

powerfx

Patch(Issues, ThisItem, 
      { Status: { Value: "Closed" } } );

This will set the Status choice to “Closed” [rezadorrani.com]. If you are using a dropdown tied to the choice field, you can simplify it:

powerfx

// drpStatus is a dropdown with Items = Choices(Issues.Status)
Patch(Issues, ThisItem,
      { Status: drpStatus.Selected } );

In this case, drpStatus.Selected returns a record like { Value: "Closed" } for the chosen option, so it matches what Patch needs [powerapps911.com].

Notes & Pitfalls:

Value must match an option: Unlike lookups, SharePoint can accept values not in the predefined choices (it will still save the text) [powerapps911.com], but it’s not recommended unless the column allows fill-in choices. Stick to the defined options to avoid confusion. If you patch {Value: "NewOption"} that wasn’t in the list, the item might show that value but the choice field in list settings won’t automatically update to include it.
No need for Id: Choice options don’t have item IDs like lookups; just the text value suffices (with the record wrapper). If you attempt to patch just the plain text (e.g. {Status: "Closed"}), it will error – you need the {Value: "Closed"} wrapper unless using a bound control.
Case sensitivity: Choice matching is typically case-insensitive, but it’s best to use the exact casing as defined. “closed” might still patch to “Closed” but to avoid any unpredictable behavior use the exact string.
Clearing a choice: If the choice field is not required and you want to blank it out, you might try {Status: Blank()}. However, since it expects a record, you should supply {Status: { Value: "" }} (empty string) or use the bound control approach by selecting no value (if the control allows). An empty Value record will clear it, provided the field is not required.

Patching a Choice Column (Multi-Select)

SharePoint Column Setup: A multi-select Choice column lets users select multiple values from a set of options (SharePoint displays these as a list of selected values). In Power Apps, this field is represented as a table of records, each record having a Value for one choice [rezadorrani.com].

Patch Formula (Multi-Choice Example): Patching requires constructing a table of choice values. For example, suppose Tags is a multi-select choice column and we want to set it to “Red” and “Blue”:

powerfx

Patch(Issues, Defaults(Issues),
      { Tags: Table( {Value: "Red"}, {Value: "Blue"} ) } );

This will create a new issue with Tags containing those two choices [rezadorrani.compowerapps911.com]. If you have a ComboBox for this field, the formula is simpler:

powerfx

// cmbTags is a ComboBox with Items = Choices(Issues.Tags) and multiple selection enabled
Patch(Issues, Defaults(Issues),
      { Tags: cmbTags.SelectedItems } );

Here, cmbTags.SelectedItems already returns a table of {Value: "..."} records for the selected options [matthewdevaney.com]. This approach offloads the heavy lifting to the control.

Notes & Pitfalls:

Table structure: The Patch must receive a table of choice records. If you accidentally pass a single record or a single text value, you’ll get an error. Even if selecting one item, it should be in a table (e.g. Table({Value:"Red"})).
Empty selection: To clear a multi-choice field, provide an empty table. For example, {Tags: Table()} will remove all choices (ensure the column allows empty). Using cmbTags.SelectedItems when nothing is selected also yields an empty table to patch.
Limit on options: SharePoint multi-choice fields have an upper limit (usually 255 characters total or a certain count of options). This isn’t usually hit unless you have dozens of options selected. Just be aware if you ever try to patch an extremely large set of choices, SharePoint might reject it.
Common mistake: Forgetting to use Table() for multiple values. If you do { Tags: {Value:"Red"}, {Value:"Blue"} } by accident (missing the wrapping Table function), you’ll have a syntax error. Always wrap multiple records in a Table() or use a collection/SelectedItems.

Patching a Person (People Picker) Column – Single Person

SharePoint Column Setup: A Person or Group column in SharePoint references a user (from Azure AD or SharePoint site) or a SharePoint group. It’s essentially a special lookup to the hidden User Information list. In a canvas app, a Person field appears as a record with various fields like Claims, DisplayName, Email, etc. The Claims is a key identifier string that SharePoint uses to identify the user (it includes the user’s principal info). Typically, to patch a person field, you supply a record with at least the Claims (and often Email, DisplayName, etc., though SharePoint can fill some of those if Claims is provided) [powerapps911.com].

Patch Formula (Single Person Example): Imagine a “AssignedTo” field that is a single-person column. To patch it to a specific user, say “[email protected]”:

powerfx

Patch(Tasks, LookUp(Tasks, ID=1), 
      { AssignedTo: {
            Claims: "i:0#.f|membership|john.doe@contoso.com",
            DisplayName: "John Doe",
            Email: "john.doe@contoso.com",
            Department: "", JobTitle: "", Picture: ""
        } } );

This updates item ID 1’s AssignedTo to John Doe [rezadorrani.com]. The Claims string format "i:0#.f|membership|user@domain.com" is the typical claim for a user in SharePoint Online (using Azure AD authentication). In the above, we provided the user’s email in both Claims and Email, and a DisplayName. In fact, only the Claims field is technically required for SharePoint to resolve the user [powerapps911.com], but it’s a good practice to include Email and DisplayName for clarity. (SharePoint will match the claim to the actual user account and populate the name in the list interface regardless.)

Easier method: Manually building that record is error-prone. A simpler way is to use a People Picker control (ComboBox) tied to the Person field. For example, if you include the field in an Edit form, the data card value for AssignedTo will be a combobox (cmbAssignedTo). If you set up a combobox yourself, use Items = Office365Users.SearchUser() or Items = Choices(Tasks.AssignedTo) (Choices on a person field returns the list of site users). Then:

powerfx

Patch(Tasks, LookUp(Tasks, ID=1),
      { AssignedTo: cmbAssignedTo.Selected } );

If cmbAssignedTo is single-select (or a Dropdown bound to Choices(Tasks.AssignedTo)), Selected will be a user record with the correct structure (including Claims, etc.) [matthewdevaney.com]. This way, you avoid manually concatenating the claims.

Notes & Pitfalls:

Ensure the user exists: The email or claim must correspond to an existing user in the tenant or allowed visitors. If you try to patch a claim that SharePoint can’t resolve to a user, it will error. Using the Office365Users connector to find the user by email and then patching the result is a reliable pattern.
Claims format: For Azure AD accounts in SharePoint Online, the claim usually starts with "i:0#.f|membership|" followed by the UPN (email). If your tenant uses a different auth provider or you’re on-prem, the claims identity could differ (e.g. "i:0#.w|domain\\username" for Windows auth). This typically only matters if you manually build the string. Using User().Email as shown in our formula (with Concatenate in Reza’s example [rezadorrani.com]) or a selected user record avoids guessing the format.
Single vs multiple: A single-person field must receive a single record (not a table). Conversely, a multi-person field (see next section) expects a table of such records. If you accidentally pass a single record to a multi-person field or vice versa, Patch will throw an error about type mismatch.
Clearing the person field: To remove a person, you can patch Blank() or a blank record. Often easiest is to patch AssignedTo: Blank() if the field is not required. Alternatively, {AssignedTo: { Claims:"", DisplayName:"", Email:"" }} might also clear it (the exact method can vary; Blank() is simplest when allowed).

Patching a Person Column – Multiple Selections

SharePoint Column Setup: A Person/Group column can be configured to allow multiple people. In SharePoint, multiple persons are stored similarly to multi-choice: an array of people entities. In Power Apps, you will handle it as a table of user records (each record with Claims, Email, etc., like the single-person case) [powerappsguide.compowerappsguide.com].

Patch Formula (Multi-Person Example): Let’s say “TeamMembers” is a multi-select person column in a Projects list. To patch two users (e.g. John and Jane) into it:

powerfx

Patch(Projects, Defaults(Projects),
      { TeamMembers: Table(
            {
               Claims: "i:0#.f|membership|john.doe@contoso.com",
               DisplayName: "John Doe", Email: "john.doe@contoso.com",
               Department: "", JobTitle: "", Picture: ""
            },
            {
               Claims: "i:0#.f|membership|jane.smith@contoso.com",
               DisplayName: "Jane Smith", Email: "jane.smith@contoso.com",
               Department: "", JobTitle: "", Picture: ""
            }
      ) } );

This creates a new Project item with John and Jane in the TeamMembers field [matthewdevaney.commatthewdevaney.com]. As with single, only the Claims are strictly required for each, but we included names and emails for completeness.

Easier method: Use a ComboBox that allows multiple selection. For example, set cmbTeam.Items = Choices(Projects.TeamMembers) (this will list possible users – it might list all users or a subset like users of the site). Ensure cmbTeam.AllowMultipleSelection = true. Then simply:

powerfx

Patch(Projects, Defaults(Projects),
      { TeamMembers: cmbTeam.SelectedItems } );

If John and Jane are selected in the combo box, cmbTeam.SelectedItems will be a table of user records (each with Claims, DisplayName, etc.) that Patch can directly use [matthewdevaney.com]. This is much simpler and less error-prone.

Notes & Pitfalls:

Table of records: Just like multi-choice, you must send a table. A single record or a single value won’t work. Conversely, for a single-person field, don’t send a table.
Ordering and duplicates: The order of people in the table typically doesn’t matter; SharePoint will store them in some default order (often alphabetically by name). Avoid duplicate entries in the table – if the same person appears twice, SharePoint might either deduplicate or throw an error.
Adding/removing individuals: If you want to append or remove a person without disturbing others, you’ll need to retrieve the current value (e.g. use Collect or manipulate the SelectedItems of a combo). Patch on its own replaces the entire field value. For example, to add a person, you could do: {TeamMembers: Table( <Existing team members...>, {Claims:"…newperson…", ...} ) }. But typically, you would manage this through the UI by using a combo box selection.
User not found error: If one of the entries isn’t recognized as a valid user, the whole Patch fails. Double-check spelling of emails or ensure the user has access to the site (they might need to be added in Azure AD or as a guest).

Patching a Hyperlink (URL) Column

SharePoint Column Setup: A Hyperlink column in SharePoint consists of two parts: URL and Description. In list views, SharePoint either displays the description text as a clickable link or (if the column is set to “Picture” format) displays the URL’s target image. When connecting to Power Apps, a hyperlink field is typically treated as a string (especially in newer connectors). In older implementations, one could patch a record like {URL: "...", Description: "..."}. However, currently the recommended approach is to patch just the URL as text [powerapps911.compowerapps911.com].

Patch Formula (Hyperlink Example): If Website is a Hyperlink field (with an optional description) and you want to set it to https://contoso.com with description “Contoso Site”, you might expect to do {URL:"https://contoso.com", Description:"Contoso Site"}. But the SharePoint connector will actually take a simple text for the URL:

powerfx

Patch(Projects, Defaults(Projects),
      { Website: "https://contoso.com" } );

This will set the hyperlink value to “https://contoso.com”. The description part cannot be set via Patch – by default, SharePoint will display the URL as the clickable text, or if the column was previously set with a description, that description may remain unchanged if you only patch the URL. Essentially, Power Apps only writes to the URL component with Patch [powerapps911.com].

If you want to allow user input for both URL and Description, one workaround is to combine them into a single string like "URL, Description" and patch that. However, the easier method is to use an Edit form for that field or a Power Automate flow. For simplicity, assume we only care about the URL in this example.

Notes & Pitfalls:

Description is read-only in Patch: As mentioned, you cannot directly set the Description through Patch (there is no supported structure in the current connector to do so). So whatever string you patch is taken as the URL. The Description will either remain what it was or mirror the URL. In many cases, SharePoint will set the Description equal to the URL if none is provided. So don’t be surprised if the link text is the URL after patching.
Picture format limitation: If the hyperlink column is configured to show as an image (picture), patching via Power Apps is not supported [powerapps911.com]. You would need to switch the column to hyperlink format (or use a different approach like an attachment or image column). In picture mode, SharePoint expects an image URL and possibly handles it differently, which the Patch function can’t fulfill. The PowerApps911 reference states that you cannot patch a hyperlink column when it’s set to picture mode [powerapps911.com]. The workaround is to change the column display to standard hyperlink if you need to Patch it.
Validation: Ensure the string is a valid URL (starts with http:// or https:// or other supported scheme). SharePoint might reject obviously malformed URLs. If the user omits the scheme (e.g. types “www.contoso.com”), you might need to prepend “https://” in your patch formula.
Alternate approach for description: If a description is crucial, one approach is to concatenate URL and description in a single string separated by comma in a Single Line Text field and then use SharePoint column formatting or a flow to split them. But that’s beyond this scope – generally, consider using the hyperlink column primarily for URL storage when patching from Power Apps.

Patching a Yes/No (Boolean) Column

SharePoint Column Setup: A Yes/No column is a boolean value (stored as true/false in SharePoint, displayed as Yes/No). In Power Apps, it appears as a boolean (true/false) value. Patching it is straightforward with a boolean literal or a control that provides boolean.

Patch Formula (Yes/No Example): For a field “Approved” (Yes/No) that we want to set to Yes (true):

powerfx

Patch(Requests, ThisItem, { Approved: true } );

This marks the Approved column as “Yes” [powerapps911.com]. Conversely, use false for “No”. If using a toggle or checkbox control, you can patch its .Value:

powerfx

Patch(Requests, ThisItem, { Approved: chkApproved.Value } );

Here, chkApproved.Value is either true or false depending on the user’s selection (for a Check box, Value is true when checked; for a Toggle, use Toggle1.Value) [powerapps911.com].

Notes & Pitfalls:

Boolean type: Use actual boolean values (true/false). You might see some sources using 1 or 0 to represent true/false [rezadorrani.com]. In fact, Patch will accept 1 as true (Yes) and false as No in some cases [rezadorrani.com], but for clarity stick to explicit booleans. Do not use the strings "Yes"/"No" – that will cause a type mismatch.
Default values: If the SharePoint column has a default (Yes or No), and you are creating a new item with Patch without specifying that field, SharePoint will apply its default (unlike some fields where a missing value is just blank, booleans will default to either yes or no per the list setting).
Nullability: SharePoint Yes/No fields cannot be null – they are always either Yes or No. In Power Apps, if you treat it as a required field, make sure to provide true or false. If you use a checkbox that is not defaulted, its Value might start as false (No). Just be mindful that leaving it “unset” in UI still results in a value (false if unchecked).
Common pitfall: If you accidentally patch a Yes/No field with a text value like "true"/"false" (as strings) or "Yes", it will error. Ensure no quotes around true/false in your formula.

Patching a Managed Metadata (Tag) Column (Single Value)

SharePoint Column Setup: Managed Metadata columns connect to the Term Store, allowing you to tag items with taxonomy terms. These are one of the more complex field types to patch because the record requires multiple pieces of information about the term. A single-value Managed Metadata field in Power Apps is represented as a record with fields including TermGuid, Label, WssId, Path, and Value [rezadorrani.com]. Essentially, you must tell SharePoint which term to apply by its GUID and provide the text label.

For example, suppose we have a “Department” Managed Metadata column that points to a term set of departments. We want to patch the term “Finance” which has a known Term GUID.

Patch Formula (Managed Metadata Example):

powerfx

Patch(Docs, Defaults(Docs),
      { Department: {
           '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedTaxonomy",
           TermGuid: "b8c3899a-5d9e-4f7c-8ced-8c2f761b9e75",
           Label: "Finance",
           WssId: -1,
           Path: "Finance",
           Value: "Finance"
      } } );

This will create a new item in Docs with the Department metadata set to the term Finance identified by that GUID [community.powerplatform.comcommunity.powerplatform.com]. Let’s break down the fields:

TermGuid: The unique identifier of the term in the term store (you often have to get this from SharePoint’s term store or via a query).
Label: The term’s name as you want it displayed.
Path: The full hierarchical path of the term (for nested terms). In this case “Finance” has no parent so Path could be just "Finance". Often this can be an empty string if not needed.
WssId: An internal ID used by SharePoint for caching terms in the site collection; setting it to -1 or 0 indicates “not cached yet, resolve by TermGuid” [powerappsguide.com]. Common practice is to use -1 or 0 when patching; SharePoint will assign the correct WssId.
Value: Historically used similarly to Label (sometimes redundant). Including it as blank or same as Label is fine. The key ones are TermGuid and Label (and providing all expected fields to avoid errors) [powerapps911.com].

The @odata.type is also provided to tell the connector which data type this is (taxonomy type). If you use the Choices function or connect the field to a control, this might be handled for you.

Easier method: If your app can get the term information through a control, that helps. Unfortunately, Power Apps does not have a built-in Choices() for taxonomy that returns all terms (unless the terms are used in that list already). One approach is to use a ComboBox and a custom source (for example, a SharePoint Online connector call or a predefined list of terms, or use the DataCard from an edit form). If you have the term GUID and label available (perhaps via a dropdown of term names tied to some data source), you can construct the record as above. There isn’t a straightforward out-of-the-box combo bound to Choices(List.Column) for taxonomy, because it doesn’t enumerate terms. Often, people use a separate hidden list or manual entry of terms to drive selection.

However, if you do use the default SharePoint form integration or a custom form with the taxonomy control, you can patch using that control’s selected item. For example, if cmbDept is a combo box inside a form data card for Department:

powerfx

Patch(Docs, Defaults(Docs),
      { Department: cmbDept.Selected } );

In a SharePoint-integrated app, cmbDept.Selected might already be a record with the needed term fields (TermGuid, Label, etc.) as provided by the form’s data source. Always verify what structure Selected has by testing or looking at its properties.

Notes & Pitfalls:

All fields required: When manually patching, provide all the fields (TermGuid, Label, etc.) for the term [community.powerplatform.comcommunity.powerplatform.com]. If any is missing, Patch will likely fail. For example, a known pitfall is to omit WssId – this can cause a network error. Use WssId: -1 (or 0 as some use) if you don’t have one. It signals SharePoint to resolve the term.
Getting TermGuid: You usually need to fetch the GUID of the term. This might involve using the SharePoint REST API or a manual lookup. For a beginner, if you’re just testing, you can get the GUID by looking at term store settings or by temporarily using a SharePoint form to set a value and then reading it in Power Apps. Community blogs often show using a hidden data card to grab DataCardValue.Selected.TermGuid [community.powerplatform.com] – which is exactly how one would do it inside an edit form scenario.
Multi-language labels: If your term store has multiple language labels, the Label you patch should match one of the labels. Typically it’s the default language label.
Single vs multi: For a single-value metadata column, supply a record. Let’s discuss multiple next.

Patching a Managed Metadata Column (Multi-Select)

SharePoint Column Setup: A Managed Metadata column can allow multiple tags to be assigned. This behaves like a multi-select choice in concept, but with terms. You will need to patch a table of term records in this case [powerapps911.compowerapps911.com].

Patch Formula (Multi-Taxonomy Example): Suppose “Categories” is a multi-select Managed Metadata field, and we want to tag an item with two terms: Finance (GUID aaaa...) and Healthcare (GUID bbbb...):

powerfx

Patch(Docs, LookUp(Docs, ID=1),
      { Categories: Table(
            {
               '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedTaxonomy",
               TermGuid: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
               Label: "Finance",
               WssId: -1, Path: "Finance", Value: "Finance"
            },
            {
               '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedTaxonomy",
               TermGuid: "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb",
               Label: "Healthcare",
               WssId: -1, Path: "Healthcare", Value: "Healthcare"
            }
      ) } );

This updates item ID 1’s Categories field to contain the Finance and Healthcare tags [powerapps911.compowerapps911.com]. As you can see, it’s verbose – each term needs the full record as in the single case.

Easier method: Similar to multi-choice or multi-person, using a ComboBox that allows multiple selection can simplify things if you have a way to feed the terms into it. If you set cmbCategories.Items to a list of term labels or a custom data source of terms (e.g. from a SharePoint list that mirrors the term set), you could then collect the GUID and label on selection. But out of the box, Power Apps doesn’t directly pull term store data without a connector or custom approach. Another approach is to use the SharePointIntegration in customized forms (when customizing a SharePoint list form with Power Apps, the taxonomy control is provided). In that case, the combobox inside the data card will manage the terms. You could patch using cmbCategories.SelectedItems which would be a table of term records already formatted. This is advanced, though.

For beginners, if you need multi-terms, consider patching one term at a time (e.g. if user selects multiple, you can build the table as above in your formula). Or use an edit form which handles it automatically.

Notes & Pitfalls:

Performance: Building a big table of terms with GUIDs in the formula can be cumbersome. If the set of terms is large, consider an alternative like using Power Automate to handle taxonomy updates or limiting the number of selectable terms in the app.
Term GUID accuracy: Double-check each GUID. If one is wrong or doesn’t exist in that term set, the whole patch will fail. If a term has a duplicate label in a different part of the hierarchy, the GUID ensures the correct one is picked.
Mixing with existing tags: If you want to add a tag while keeping existing ones, you would need to retrieve the current value (which comes as a table of records) and then Collect the new one into it, then patch the combined table. If you just patch a new table, it overwrites the old tags.
Clearing tags: To remove all tags, patch an empty table: {Categories: Table()}. To remove one out of many, patch the new list of terms excluding that term’s record.
Not supported in some contexts: In older PowerApps versions, taxonomy fields were not delegable or readily accessible via Choices(). This might still be the case, so testing is important. Some makers use a hidden data card in an Edit form to leverage its combo box for term selection and then patch using that value, as a workaround for the lack of direct term querying.

Conclusion

The Power Apps Patch function is an essential tool for any app maker who wants to go beyond the limitations of standard forms. As we’ve seen, with SharePoint as a data source, Patch can handle everything from simple text and number updates to complex field types like lookups, people pickers, and managed metadata. Mastering the syntax for each column type unlocks the ability to create highly dynamic apps – for example, apps that update several lists at once, or save data in custom ways with a single button click. By using Patch, you can provide a smoother user experience (no page reloads, more control over what happens on save) and implement business logic (conditional updates, default values, etc.) in your canvas apps.

SharePoint is a great starting point because it’s readily available and easy to use. We also noted that Dataverse is the more powerful, scalable option as apps grow – but it requires premium licensing [powerapps911.com]. As your app scales up or your organization’s needs get more complex (relationships, security roles, large data volume), you might explore moving to Dataverse or SQL. The good news is that the skills you learned here with Patch and Power Fx will carry over. In Dataverse, for example, you also use Patch (though many complex field types are handled more uniformly in Dataverse).

For now, with SharePoint lists and the Patch function, you can build robust custom solutions within the standard licensing. Practice patching different field types in a test app – perhaps create a sample list with columns of each type and try the examples above. Always remember to match the data types, use the Choices() function and proper controls to simplify complex patches, and handle any errors (use IfError or check the return value of Patch) to make your app user-friendly.

Happy patching, and enjoy the flexibility it brings to your Power Apps development! If you found this guide helpful, you’re well on your way to building apps that save data exactly how and when you want. Keep experimenting with Patch, and soon it’ll become second nature.

References

Microsoft Learn – Patch function documentation: Official reference for Patch syntax and usage in Power Fxlearn.microsoft.comlearn.microsoft.com.
Power Apps & SharePoint Complex Fields – Reza Dorrani’s Blog: “Power Apps Patch function with SharePoint” – outlines Patch syntax for SharePoint columns like Choice, People, Lookup, etc., including required record structuresrezadorrani.comrezadorrani.com.
PowerApps911 – Patching Complex SharePoint Columns: Shane Young’s tutorial on patching choice, multi-choice, people, multi-people, lookup, and managed metadata fields (both with static values and using controls)powerapps911.compowerapps911.com. Great best practices on using Dropdowns/ComboBoxes with Choices() to simplify Patch.
Power Apps Community Blog – Managed Metadata Patch: “Saving to SharePoint Managed Metadata columns using Patch” by Darogael – shows how to construct the record for taxonomy fields with TermGuid, Label, etc.community.powerplatform.comcommunity.powerplatform.com.
Power Apps Guide by Tim Leung – Patching complex data types: Summarizes the Patch syntax for the 6 most complex SharePoint field types (lookup, single choice, multi-choice, yes/no, person, multi-person) with examplespowerappsguide.compowerappsguide.com. A handy reference for understanding the OData type requirements and structures.
Matthew Devaney – Patch Function Examples: A collection of examples for every SharePoint column type. Useful for seeing real examples with screenshots of before/after in the SharePoint listmatthewdevaney.commatthewdevaney.com. Matthew’s site also provides a PDF guide which is great for offline reference.
PowerApps Official Forum Q&A: Various community answers and threads (on Power Users and Stack Exchange) discussing common Patch errors (e.g., “Network error when using Patch” which often means invalid data or missing required fields). These can be useful if you run into specific issues not covered above.
Dataverse vs SharePoint for Power Apps – Overview: Blog post “Getting Started with Dataverse: A SharePoint User's Guide” on PowerApps911 highlights key differences (e.g., Dataverse requires premium licenses, whereas SharePoint is included in M365)powerapps911.com. Good to read when you’re considering scaling up from SharePoint in the future.

Search This Blog

That O365 Guru from Cape Town (#NadirKamdar)