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.
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 cardValidproperties. - 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 Name | Data Type |
|---|---|
| EmployeeName | Single line of text |
| CourseName | Single line of text |
| CompletionDate | Date and Time |
| Score | Number |
| Status | Choice (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):
- Employee Name – Text input (name it
txt_EmployeeName) - Course Name – Text input (
txt_CourseName) - Completion Date – Date picker (
dp_CompletionDate) - Score – Text input (
txt_Score) - Status – Dropdown (
dd_Status).
Set the Items property of the dropdown to:
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:
- The data source (e.g.
'Training Records') - The base record – use
Defaults('Training Records')to indicate a new record, or a variable for an existing record when editing. - A record of column-value pairs.
In the OnSelect property of btn_Submit, write:
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
}
)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:
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:
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
Patchfunction itself is not delegation‑aware; it sends a single record per call. This is fine for typical form submission scenarios. - Network Round‑Trips – Every
Patchcall travels to the data source. Avoid callingPatchin a loop – useCollecton 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
Errorsfunction 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
Patchwhen connectivity is restored.
Common Mistakes & Troubleshooting
| Mistake | Symptom | Solution |
|---|---|---|
Forgetting Value() for numbers | Patch fails with type mismatch | Wrap text input in Value() |
Using Text on a date picker | Date is stored as text string | Use SelectedDate or SelectedDate for DatePicker |
Not checking Errors | User never knows if save failed | Always inspect Errors after Patch |
| Referencing wrong column name | Patch succeeds but column is empty | Double‑check the internal name of SharePoint columns |
| No validation | Blank or out‑of‑range data gets submitted | Set 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
- Original article: Matthew Devaney, Everything You Need To Know About Power Apps Patch Forms
- Microsoft Learn: Patch function in Power Apps (placeholder – verify URL)
- Microsoft Learn: Errors function in Power Apps (placeholder – verify URL)
Learn how small coding practices—like using descriptive names, flattening conditions, and simplifying logic—can make your apps easier to update and less error-prone.
Move past the gallery and discover the hidden patterns for validation, navigation, and smart submission handling in your data entry forms.
PowerShell unlocks admin capabilities that the Power Platform admin center simply doesn’t offer—from recovering deleted apps to blocking trial licenses. Here’s how to wield them safely.