Tutorials/Power Apps/Mastering Patch Forms in Power Apps: Design, Validation, and Error Handling
Power Appsintermediate

Mastering Patch Forms in Power Apps: Design, Validation, and Error Handling

Learn why and how to build custom forms with the Patch function instead of relying on Edit forms, with a real-world example.

NA
Narmer Abader
@narmer · Published June 3, 2026

Power Apps gives you two primary ways to create data-entry forms: the built-in Edit form control and the more flexible Patch form approach. Edit forms are great when you need a quick, standardised data entry experience with minimal effort. But once you outgrow the rigid layout, need full control over every pixel, or want to write back to local collections for offline scenarios, Patch forms become your best friend.

In this guide you’ll build a Training Tracker app from scratch. You’ll see how to plan the form, wire it up to a SharePoint list, submit records with the Patch function, validate input before submission, and handle errors gracefully – all without an Edit form control.

When a Patch Form Makes Sense

Edit forms automatically generate input controls from your data source and provide built-in SubmitForm, OnSuccess, and OnFailure events. They are the fastest way to get a form running. However, you might want to switch to a Patch form when:

  • You need complete freedom over the visual design – custom colours, non‑standard layouts, and mixing controls that Edit forms don’t support natively.
  • You want to reuse the same input values across multiple screens or write them to a local collection for later synchronisation.
  • You prefer to write validation logic in one place (the submit button’s DisplayMode) rather than spreading it across individual card Valid properties.
  • You need to patch data to more than one data source (e.g. SharePoint and a SQL table) in a single transaction.

Patch forms require a bit more manual work, but the payoff in flexibility is often worth it.

The Training Tracker Scenario

Your company runs a learning management program. You need a simple app where HR staff can record when an employee completes a course, along with the score and a pass/fail status. The app must prevent submission if fields are empty or the score is out of range.

SharePoint List Setup

Create a new SharePoint list called Training Records with these columns:

Column NameData Type
EmployeeNameSingle line of text
CourseNameSingle line of text
CompletionDateDate and Time
ScoreNumber
StatusChoice (Pass, Fail)

No initial data is required – the list will be filled by the form.

Building the Form Layout

Open Power Apps Studio and create a new blank app. Rename the default screen to TrainingFormScreen. Add a label at the top with the text “Training Tracker” to act as a title.

Connect your app to the Training Records SharePoint list.

Now manually add the following controls (each with a label and an input control):

  1. Employee Name – Text input (name it txt_EmployeeName)
  2. Course Name – Text input (txt_CourseName)
  3. Completion Date – Date picker (dp_CompletionDate)
  4. Score – Text input (txt_Score)
  5. Status – Dropdown (dd_Status).

Set the Items property of the dropdown to:

powerfxPopulate dropdown choices
Choices('Training Records'.Status)

Position the controls in a clean vertical stack. Finally, add a button labelled “Submit Training Record” at the bottom. Name it btn_Submit.

Submitting Data with the Patch Function

The core of a Patch form is the Patch function. It takes three arguments:

  1. The data source (e.g. 'Training Records')
  2. The base record – use Defaults('Training Records') to indicate a new record, or a variable for an existing record when editing.
  3. A record of column-value pairs.

In the OnSelect property of btn_Submit, write:

powerfxSubmit button OnSelect
Patch(
  'Training Records',
  Defaults('Training Records'),
  {
      EmployeeName: txt_EmployeeName.Text,
      CourseName: txt_CourseName.Text,
      CompletionDate: dp_CompletionDate.SelectedDate,
      Score: Value(txt_Score.Text),
      Status: dd_Status.Selected
  }
)
Tip

Always use the Value function to convert text input to a number when patching a numeric column. Failing to do so will cause a type mismatch error.

Checking for Errors After Submission

Edit forms have built-in OnSuccess and OnFailure events. Since you’re building a Patch form, you must check for errors yourself. The Errors function returns a table of errors from the last data operation for a given source. If it’s empty, the operation succeeded.

Update the OnSelect to include error handling:

powerfxSubmit with error notification
Patch(
  'Training Records',
  Defaults('Training Records'),
  {
      EmployeeName: txt_EmployeeName.Text,
      CourseName: txt_CourseName.Text,
      CompletionDate: dp_CompletionDate.SelectedDate,
      Score: Value(txt_Score.Text),
      Status: dd_Status.Selected
  }
);
If(
  IsEmpty(Errors('Training Records')),
  Notify("Training record saved successfully", NotificationType.Success),
  Notify("Error: record could not be saved", NotificationType.Error)
)

Validating Form Data Before Submission

A good user experience prevents invalid submissions before they reach the server. In a Patch form you control the submit button’s DisplayMode property. When validation fails, disable the button.

Set the DisplayMode of btn_Submit to:

powerfxDisplayMode validation
If(
  Or(
      IsBlank(txt_EmployeeName.Text),
      IsBlank(txt_CourseName.Text),
      IsBlank(dp_CompletionDate.SelectedDate),
      IsBlank(txt_Score.Text),
      IsBlank(dd_Status.Selected),
      Value(txt_Score.Text) < 0,
      Value(txt_Score.Text) > 100
  ),
  DisplayMode.Disabled,
  DisplayMode.Edit
)

The button will remain disabled until all fields are filled and the score is between 0 and 100.

Security, Performance & Delegation Notes

  • Data Source Limits – The Patch function itself is not delegation‑aware; it sends a single record per call. This is fine for typical form submission scenarios.
  • Network Round‑Trips – Every Patch call travels to the data source. Avoid calling Patch in a loop – use Collect on a collection and then patch the collection in one operation if possible.
  • Permissions – Ensure the app’s user has at least Contribute permissions on the SharePoint list. The Errors function will return a permission‑related error if the user lacks write access.
  • Mobile Offline – Patch forms are a great fit for offline‑capable apps. You can write to a local collection first and later synchronise with Patch when connectivity is restored.

Common Mistakes & Troubleshooting

MistakeSymptomSolution
Forgetting Value() for numbersPatch fails with type mismatchWrap text input in Value()
Using Text on a date pickerDate is stored as text stringUse SelectedDate or SelectedDate for DatePicker
Not checking ErrorsUser never knows if save failedAlways inspect Errors after Patch
Referencing wrong column namePatch succeeds but column is emptyDouble‑check the internal name of SharePoint columns
No validationBlank or out‑of‑range data gets submittedSet DisplayMode validation on the submit button

Final Recommendation

Patch forms are not a replacement for Edit forms – they are an alternative when you need more control or specific capabilities like writing to collections. Start with an Edit form if it meets your needs; switch to a Patch form when you hit a limitation.

The Training Tracker example shown here gives you a solid foundation for building any custom data entry screen. As you become more comfortable with Patch, you can extend it to handle related records, conditional logic, and even multi‑step wizards.

References