Learn how to control whether your Power Apps form creates new records, edits existing ones, or displays data as read-only — using NewForm(), EditForm(), and ViewForm(). This lesson walks you through a real employee directory app, wiring up buttons, handling submission outcomes, and building dynamic UI that responds to form state.
Imagine you're building an employee directory app for your HR team. When a new hire joins the company, HR needs to fill out a blank form and submit it. When they pull up an existing employee's record to update a phone number, the form should pre-populate with that person's current data. And when a manager just wants to look up someone's department without accidentally changing anything, they should see a read-only view. Three different situations, one form control — and the difference between each experience is a single function call.
That's the power of form modes in Power Apps. The EditForm control (the component you drop onto your canvas) can behave in three completely distinct ways depending on which mode you put it in: New, Edit, or View. Understanding how to switch between these modes — and when to use each one — is the difference between an app that feels professionally built and one that confuses its users.
By the end of this lesson, you'll have a solid grasp of how form modes work under the hood, how to trigger each mode with the right functions, and how to wire everything together so users flow naturally from browsing records to editing them to creating new ones.
What you'll learn:
NewForm(), EditForm(), and ViewForm() functions to switch between modesBefore diving in, you should be comfortable with the basics of the Power Apps canvas environment — knowing how to add controls, navigate between screens, and write simple formulas. If you haven't built anything in Power Apps yet, start with Your First Power App: Build a Data Entry Form in 30 Minutes or Build Your First Canvas App in Power Apps before continuing here.
You should also have a data source set up — this lesson uses a SharePoint list as its example, though the concepts apply equally to Dataverse, Excel, or SQL Server. If you need help connecting a data source, see Connecting Power Apps to SharePoint, Excel, and Dataverse: A Complete Integration Guide.
Before we talk about modes, let's build a mental model of what the EditForm control actually is.
When you insert a form control onto a screen (Insert → Forms → Edit), Power Apps places a container that is purpose-built for reading and writing records to a data source. It's not just a group of text boxes — it's a connected component that knows how to:
SubmitForm() callThe form control has two key properties you'll configure:
Employees (the name of your SharePoint list or Dataverse table).EmployeeGallery.Selected.Once those two are set, Power Apps automatically generates input fields for each column in your data source. You can add, remove, or reorder those fields by clicking the "Edit fields" link in the properties panel.
Note: The control is called "Edit Form" in the Insert menu, but it's capable of all three modes — New, Edit, and View. Think of "Edit Form" as the control type name, not a description of what it always does.
When you call NewForm(FormName), the form clears all its fields and presents the user with an empty input for each column in your data source. No existing record is loaded. When the user fills in the fields and you call SubmitForm(FormName), a brand-new record is created in your data source.
This is the mode you use for an "Add New Employee" workflow. The form doesn't care about FormName.Item in this mode — even if a gallery item is selected, the form ignores it and stays blank.
Under the hood, Power Apps sets the form's Mode property to FormMode.New. You can read this value back with FormName.Mode if you need your UI to react to it.
When you call EditForm(FormName), the form loads the record pointed to by FormName.Item and makes all fields editable. The user can change values, and when SubmitForm(FormName) is called, Power Apps writes the changes back to the existing record — it does not create a duplicate.
This is the mode you use when a user selects an employee in a gallery and clicks "Edit." The form populates with that person's current data, ready for changes.
Warning: If
FormName.Itemis blank when you callEditForm(), the form will display empty fields — it looks like New mode but won't behave correctly. Always make sure a record is selected before triggering Edit mode. Use a gallery selection pattern to ensure this.
When you call ViewForm(FormName), the form loads the record from FormName.Item just like Edit mode, but all input controls become read-only labels. Users can see the data but cannot change it.
This is the mode for a "Record Detail" view — a manager checking an employee's start date or department without the risk of accidentally overwriting anything.
Key insight: View mode is not just cosmetic. The form controls physically switch from inputs (TextInput, DatePicker, etc.) to display labels. That means there's no way for the user to accidentally tab into a field and change it. It's a genuine enforcement of read-only access, not just a visual hint.
Let's build a concrete example: an Employee Directory app with a gallery screen and a detail/edit screen. The data source is a SharePoint list called Employees with columns: Title (employee name), Department, Email, StartDate, and Phone.
Open Power Apps Studio and create a new blank canvas app. In the left sidebar, click the Data icon (cylinder shape), then click "Add data." Search for your SharePoint connector, connect to your site, and select the Employees list. The list now appears under Data in the left panel.
Rename your first screen to BrowseScreen. Insert a Vertical Gallery (Insert → Gallery → Vertical). Set its Items property to:
Employees
In the gallery's template, add a label for the Title field. Set its Text property to ThisItem.Title. Add a second label for Department: ThisItem.Department.
Now insert three buttons below or alongside the gallery: Add New, Edit, and View. We'll wire these up in a moment.
Add a new screen and rename it DetailScreen. Insert an Edit Form control (Insert → Forms → Edit). Rename it EmployeeForm.
In the properties panel on the right:
EmployeesBrowseScreen.EmployeeGallery.SelectedTip: Naming your gallery (
EmployeeGallery) and form (EmployeeForm) with descriptive names instead of the defaults (Gallery1,Form1) makes formulas far easier to read and debug, especially as your app grows.
Now click "Edit fields" in the properties panel and make sure all five columns are listed: Title, Department, Email, StartDate, Phone. Reorder them as needed by dragging.
Go back to BrowseScreen. Select the Add New button and set its OnSelect property to:
NewForm(EmployeeForm);
Navigate(DetailScreen, ScreenTransition.Slide)
This clears the form and navigates to the detail screen in one action. The semicolon chains two formulas together — Power Apps executes them left to right.
Select the Edit button and set its OnSelect to:
EditForm(EmployeeForm);
Navigate(DetailScreen, ScreenTransition.Slide)
Select the View button and set its OnSelect to:
ViewForm(EmployeeForm);
Navigate(DetailScreen, ScreenTransition.Slide)
Notice the pattern: all three buttons navigate to the same screen, but each pre-sets the form to a different mode before the navigation happens. The user lands on DetailScreen and sees the appropriate experience immediately.
On DetailScreen, add three buttons: Save, Cancel, and Edit (in case the user arrived in View mode and wants to switch to Edit).
Save button OnSelect:
SubmitForm(EmployeeForm)
Cancel button OnSelect:
ResetForm(EmployeeForm);
Navigate(BrowseScreen, ScreenTransition.Back)
Edit button OnSelect (for promoting View mode to Edit mode in place):
EditForm(EmployeeForm)
ResetForm() is worth explaining: it reverts any unsaved changes the user made in the form back to the original values from the data source. It does not navigate anywhere — that's why we chain it with Navigate() for the Cancel button. Think of it as "undo everything and go back."
Tip: You can conditionally show or hide the Edit button based on the current form mode. Set the button's
Visibleproperty toEmployeeForm.Mode = FormMode.View. This way it only appears when the form is in read-only mode, which feels cleaner for users.
SubmitForm() is asynchronous — it talks to your data source and either succeeds or fails. You need to handle both outcomes.
The form control exposes two properties for this:
SubmitForm() completes successfullySubmitForm() encounters an errorSelect EmployeeForm and set its OnSuccess property to:
Navigate(BrowseScreen, ScreenTransition.Back);
Notify("Record saved successfully.", NotificationType.Success)
Set its OnFailure property to:
Notify("Something went wrong: " & EmployeeForm.Error, NotificationType.Error)
EmployeeForm.Error is a text property that Power Apps populates with a description of what failed — for example, a connectivity issue or a validation error from the data source. Surfacing this to the user (rather than silently failing) is critical for usability.
Warning: Don't put navigation inside the Save button's
OnSelectproperty. Navigation should happen inOnSuccess— not on button click — because the submit is asynchronous. If you navigate immediately on button click, you'll leave before the record is saved, potentially missing errors entirely.
Sometimes you need your app to behave differently depending on the current form mode. Power Apps gives you a clean way to check this.
The EmployeeForm.Mode property returns one of three values:
| Value | Meaning |
|---|---|
FormMode.New |
Form is in New mode |
FormMode.Edit |
Form is in Edit mode |
FormMode.View |
Form is in Read-only mode |
You can use this in If() formulas anywhere in your app. For example, set the screen title label's Text property to:
If(
EmployeeForm.Mode = FormMode.New, "Add New Employee",
EmployeeForm.Mode = FormMode.Edit, "Edit Employee",
"Employee Details"
)
Now your screen header updates automatically to reflect what the user is doing. This single formula makes the app feel polished without any extra logic.
For more complex dynamic UI patterns, explore Building Multi-Screen Apps with Navigation and Variables in Power Apps, which covers how to pass context between screens to drive these kinds of conditional behaviors.
Here's something that trips up almost every beginner: when you call NewForm(), the form's Item property doesn't change. If a gallery item was previously selected, BrowseScreen.EmployeeGallery.Selected still points to that record. But because the form is in New mode, it completely ignores the Item property and shows empty fields.
This is intentional and correct behavior. But it can cause confusion if you check Item elsewhere in your app and expect it to be blank after calling NewForm().
If you need to explicitly clear a selection, you can use a context variable as a workaround:
// On BrowseScreen, Add New button:
UpdateContext({selectedEmployee: Blank()});
NewForm(EmployeeForm);
Navigate(DetailScreen, ScreenTransition.Slide)
Then set EmployeeForm.Item to selectedEmployee instead of EmployeeGallery.Selected. When the variable is blank, Edit and View modes will load nothing (which you'd prevent by checking first), but New mode still works correctly.
For a deeper dive into how variables work in Power Apps and when context variables are the right tool, see Power Apps Variables Explained: When to Use Global Variables, Context Variables, and Collections in Canvas Apps.
Build the Employee Directory app described in this lesson from scratch. Use a SharePoint list (or a Dataverse table if you prefer) with at least four columns.
Your checklist:
BrowseScreen with a gallery showing employee names and departmentsDetailScreen in the correct modeDetailScreen, add the EmployeeForm connected to your data source with Item pointing to the gallery selectionOnSuccess to navigate back and show a success notificationOnFailure to display the error messageEmployeeForm.ModeVisible propertyTest by: adding a new employee, viewing an existing one, editing that same one, and canceling mid-edit to confirm no changes were saved.
The form shows blank fields when I click Edit
Almost always this means FormName.Item is not set correctly. Check that the form's Item property points to your gallery's .Selected property and that the gallery actually has a selected item before EditForm() is called. Use the Power Apps Monitor tool to inspect the form's Item value at runtime.
SubmitForm() in New mode creates a record with all blank fields
This usually means you called NewForm() after SubmitForm() by mistake, or the DataSource property isn't set on the form. Verify the DataSource property in the right-hand panel. Also confirm you haven't accidentally reset the form before submission.
Clicking Save navigates back but the record doesn't appear in the gallery immediately
The gallery's Items formula might be using a cached collection rather than a live query. If you're using ClearCollect() to load data, you'll need to refresh it in OnSuccess. A direct formula like Items = Employees (pointing straight to the data source) updates automatically.
The form always opens in Edit mode even after I call ViewForm()
Check whether another button or formula elsewhere is calling EditForm() and overriding your ViewForm() call. Use the Monitor tool to see which formulas are executing in order.
Required fields aren't being enforced
Power Apps respects required field settings from your data source (SharePoint required columns, Dataverse required fields) automatically. But if you've manually added card controls outside the auto-generated cards, those don't have built-in validation. Add explicit validation with IsBlank() checks before calling SubmitForm(). The lesson on Power Apps Data Validation: Using If, IsBlank, and IsMatch to Prevent Bad Data in Forms covers this in depth.
Tip: If you want to enforce that users can only edit records (not create new ones), simply don't provide a button that calls
NewForm(). The form won't enter New mode unless explicitly told to. Access control this way is simple but effective for basic scenarios. For more sophisticated security, look at Power Apps Security: Roles, Sharing, and Data Permissions.
Let's recap what you've learned:
NewForm(), EditForm(), and ViewForm() — typically on button OnSelect properties before or alongside navigationItem property tells the form which record to load for Edit and View modes; New mode ignores itSubmitForm() writes data back; ResetForm() reverts unsaved changes; both should be combined with navigation and notificationsOnSuccess and OnFailure on the form control are the right place to handle post-submission behaviorFormName.Mode lets you build dynamic UI that responds to the current form stateMastering form modes gives you the foundation to build data entry experiences that feel deliberate and professional. Your users don't have to think about what mode they're in — they just click Add, Edit, or View, and the app does the right thing.
From here, you might want to explore how to validate data before it's submitted in Power Apps Data Validation: Using If, IsBlank, and IsMatch to Prevent Bad Data in Forms, or level up your formula skills with Master Power Apps Formulas: Navigate, Filter, Lookup, and Patch for Professional Apps. If your app involves more complex data architectures — multiple related tables or high-volume scenarios — Power Apps Controls: Galleries, Forms, and Data Tables - Advanced Architecture and Performance is your next stop.