Tutorials/Power Apps/Multi-Step Data Entry Forms in Power Apps
Power Appsintermediate

Multi-Step Data Entry Forms in Power Apps

Break long forms into manageable screens using variables and Patch to submit data across pages.

NA
Narmer Abader
@narmer · Published June 3, 2026

Multi-page forms are a smart pattern when your data entry screen threatens to overflow a single view. Instead of cramming all fields onto one screen, you divide them into logical sections – each on its own page. Users can focus on one group of fields at a time, and you get cleaner navigation. In this guide we’ll build a Help Desk Ticket form that spans three screens, store the partially entered data in a variable, and finally submit the whole record using Patch. The same technique works for any long form in Power Apps.

/* TODO: Add an original screenshot showing the three-screen navigation flow */

Why Choose a Multi‑Page Form?

A single form control works well for short entries, but once you cross ten or more fields the experience becomes cramped. By spreading fields across several screens you:

  • Reduce scrolling and visual clutter.
  • Group related information (e.g., contact details, issue description, priority).
  • Validate data step by step before the final submission.
  • Keep the same form design because every page starts from a duplicated form control.

The challenge is collecting and holding data from all pages until the user is ready to save. We’ll solve that with a global record variable and the Patch function.

The Help Desk Ticket Scenario

We’ll build a ticket creation form for an internal help desk. The SharePoint list that stores the tickets has the following columns:

Column NameType
RequesterNameSingle line text
EmailSingle line text
DepartmentChoice
IssueCategoryChoice
DescriptionMultiple lines
PriorityChoice
StatusChoice

We’ll split these columns across three screens:

  • Screen 1 – Personal Info: RequesterName, Email, Department
  • Screen 2 – Issue Details: IssueCategory, Description
  • Screen 3 – Settings: Priority, Status

Users will move forward with a “Next” button and submit on the last page.

Step 1: Prepare the SharePoint List

Create a list named HelpDeskTickets with the columns above. Add a few choice fields for Department, IssueCategory, Priority, and Status (e.g., New, In Progress, Resolved). You don’t need a Title column; Power Apps will ignore it or you can hide it later.

/* TODO: Insert a screenshot of the list columns in SharePoint */

Step 2: Create the App and Add the Data Source

Open Power Apps Studio and create a blank canvas app. From the Data pane, add your HelpDeskTickets SharePoint list as a data source.

Insert a label at the top of the first screen to act as a title bar (e.g., “New Help Desk Ticket”).

Now add an Edit form control anywhere on the screen. Connect it to the HelpDeskTickets data source. The form will automatically populate with all columns. Delete the Title and Attachments fields if they appear, then set the form’s Columns to 1 and Layout to Vertical so fields stack.

Step 3: Store a Blank Record in a Variable

In the App.OnStart property, set a global variable that holds a new empty record:

powerfxApp.OnStart
Set(gblTicketRecord, Defaults('HelpDeskTickets'))

Then bind the form’s Item property to this variable:

powerfxForm.Item (first screen)
gblTicketRecord

Set the form’s DefaultMode to FormMode.New so it always starts in new-record mode.

Step 4: Duplicate Screens and Customise Fields

With the first screen ready, open the tree view, right‑click the screen, and choose Duplicate screen. Do this twice. You now have three identical screens, each with a full form.

Rename the screens and controls so you can keep track. For example:

  • Screen1_TicketPersonal (form: frmPersonal)
  • Screen2_TicketIssue (form: frmIssue)
  • Screen3_TicketSettings (form: frmSettings)

On each screen, remove the fields you don’t need and keep only the ones relevant for that page. This gives you three forms, each with a different subset of fields, but they all share the same look and feel because they originated from the same control.

/* TODO: Provide a screenshot of the tree view showing renamed screens */

Step 5: Navigate and Validate with a “Next” Button

On Screen1_TicketPersonal, add a button labelled Next. Use the following code in its OnSelect property:

powerfxNext button (Screen 1)
If(
  frmPersonal.Mode = FormMode.View,
  Navigate(Screen2_TicketIssue),
  Set(
      varValidation,
      Validate(
          'HelpDeskTickets',
          Defaults('HelpDeskTickets'),
          frmPersonal.Updates
      )
  );
  If(
      IsBlank(varValidation),
      Set(
          gblTicketRecord,
          Patch(gblTicketRecord, frmPersonal.Updates)
      );
      Navigate(Screen2_TicketIssue),
      Notify(varValidation, NotificationType.Error)
  )
)

Copy this button to Screen2_TicketIssue and adjust the form name and destination:

powerfxNext button (Screen 2)
If(
  frmIssue.Mode = FormMode.View,
  Navigate(Screen3_TicketSettings),
  Set(
      varValidation,
      Validate(
          'HelpDeskTickets',
          Defaults('HelpDeskTickets'),
          frmIssue.Updates
      )
  );
  If(
      IsBlank(varValidation),
      Set(
          gblTicketRecord,
          Patch(gblTicketRecord, frmIssue.Updates)
      );
      Navigate(Screen3_TicketSettings),
      Notify(varValidation, NotificationType.Error)
  )
)
Validation note

The Validate function checks data against constraints defined in the data source. It is not supported by every connector; if your data source doesn’t support it, you can omit the validation step or replace it with custom checks (e.g., required fields with IsBlank).

Step 6: Submit on the Final Screen

On Screen3_TicketSettings, change the button text to Submit. This button will apply the final page’s updates and then write the entire accumulated record to SharePoint.

powerfxSubmit button (Screen 3)
Set(
  gblTicketRecord,
  Patch(gblTicketRecord, frmSettings.Updates)
);
IfError(
  Patch('HelpDeskTickets', Defaults('HelpDeskTickets'), gblTicketRecord),
  Notify("Ticket created successfully", NotificationType.Success);
  ResetForm(frmPersonal);
  ResetForm(frmIssue);
  ResetForm(frmSettings);
  Set(gblTicketRecord, Defaults('HelpDeskTickets'));
  Navigate(Screen1_TicketPersonal),
  Notify(FirstError.Message, NotificationType.Error)
)

If the Patch succeeds, the user sees a success notification, forms are reset, and the app returns to the first screen ready for a new ticket.

/* TODO: Insert a screenshot showing the success notification */

Delegation, Performance, and Security Notes

  • Patch is not a delegable operation, but that’s irrelevant here because you’re only ever writing a single record.
  • The Validate function runs client‑side and does not affect delegation.
  • When using SharePoint as a data source, keep in mind that each Patch call counts toward the API throttling limits. For a simple form, this is negligible.
  • Never expose sensitive form data in a global variable that could be read by other screens unintentionally. Scope your variables appropriately (e.g., using app‑level or screen‑level context).
  • If your app must handle large volumes of submissions, consider using a flow or a custom connector to batch writes.

Common Mistakes and Troubleshooting

  • Forgetting to reset forms after submission causes old data to linger when the user creates a new record. Always call ResetForm and re‑initialize the record variable.
  • Validating on every screen is optional but recommended – it prevents the user from walking through several pages only to find an error on the final submit.
  • Variable name conflicts – if you reuse the same screen names or controls, the Next/Submit formulas can refer to the wrong form. Use unique, descriptive names for each screen and its form.
  • Using SubmitForm inside a multi‑page pattern – the built‑in SubmitForm only works with the current form’s data, not the data accumulated from other pages. That’s why we rely on Patch with a consolidated record.
  • Validate returns a table – checking IsBlank(varValidation) assumes no errors. If your data source supports it and returns errors, this works; otherwise you may need a different check.

Final Recommendation

Multi‑page forms built with duplicated forms and a record variable are a solid pattern for any canvas app that needs to collect more than a handful of fields. The approach is simple to set up, easy to maintain, and gives you full control over validation and navigation. For apps that need a true wizard‑style experience, consider adding a progress indicator or a back button (simply Navigate to the previous screen) – the data gathering logic remains the same.

Give it a try in your next Power Apps project. Your users will thank you for not overwhelming them with a single endless form.

References