Beyond the Basics: 10 Power Apps Form Techniques You'll Actually Use

Every Power Apps maker knows the thrill of dropping an Edit form control onto a screen, selecting a data source, and watching all the fields magically appear. It's one of the platform's most empowering "instant gratification" moments. But the gap between a basic functional form and a polished, production-ready experience is surprisingly wide.

Imagine you're building an internal IT Help Desk dashboard. The main form captures a ticket: the requester's name, category, priority, a detailed description, and an assigned technician. The default form control handles the basics, but the moment you need to handle unsaved changes, multi-page wizards, or responsive layouts, you need the advanced patterns.

These ten techniques are my go-to toolkit for tearing down the limitations of the standard form and turning it into a robust application component.

State Management and Submission Flow

1. The Single Form that Does Everything

The most common question I see from new makers is: "Do I need a separate screen for viewing and editing?". The answer is no. A single form can act as your creation, modification, and read-only surface thanks to the FormMode property.

NewForm(TicketForm);

// When the user selects a ticket to edit from a gallery
Set(varSelectedTicket, Gallery1.Selected);
EditForm(TicketForm);

// When the user wants to read the ticket details without editing
ViewForm(TicketForm);

Using ViewForm mode means you don't have to build a separate, static display screen. The same cards, text labels, and layout are reused, automatically switching input fields to read-only.

2. The Validation Gatekeeper

Users hate clicking "Submit" only to see an error message. The form control has a built-in Valid property that checks every data card against its data source rules.

If(
  TicketForm.Valid,
  DisplayMode.Edit,
  DisplayMode.Disabled
)

I use this directly in the DisplayMode of the Submit button. It blocks the action before any network call is made.

3. The Honest Feedback Loop

This is my biggest pet peeve. Do not put Notify in the OnSelect of the button along with SubmitForm.

Instead, place your feedback in the form's OnSuccess and OnFailure properties. These events fire only after the server responds.

SubmitForm(TicketForm);
Notify("Saved!", NotificationType.Success);

// TicketForm.OnSuccess
Notify("Ticket submitted successfully!", NotificationType.Success);
ResetForm(TicketForm);
Navigate(TicketListScreen, ScreenTransition.Fade);

// TicketForm.OnFailure
Notify("Failed to submit ticket. Check your connection and try again.", NotificationType.Error);

4. Capturing the Post-Submit Record

When a record is created via a form, the data source returns the fully materialized record. This includes system-generated fields like the record ID, Created By, and Created On. The LastSubmit property holds exactly this record.

// On TicketForm.OnSuccess
Set(varTicket, TicketForm.LastSubmit);

Collect(
  TicketHistory,
  {
      TicketId: varTicket.ID,
      Change: "Ticket Created"
  }
);

This eliminates the need to guess the ID of the newly created record.

5. The Safety Net for Unsaved Changes

A user fills out a long form and then accidentally clicks a navigation button. Without a safety net, all their work is gone. The Unsaved property on the form tracks precisely this: has any field value changed from its loaded or default state?

// OnSelect of the Home navigation button
If(
  TicketForm.Unsaved,
  Set(varShowUnsavedWarning, true),
  Navigate(HomeScreen, ScreenTransition.UnCover)
);

Data Control and Builder Efficiency

6. The Backstage Pass: Form Updates

Every form generates a secret payload called Updates. This record contains the exact data that would be sent to the server during a SubmitForm call. It is the sum of every card's Update property.

This is incredibly useful for debugging and for advanced patterns. For example, you can collect the form data instead of submitting it.

Collect(PendingSubmissionBatch, TicketForm.Updates);

This is my go-to pattern for offline-capable apps or when I need to batch submissions through a Power Automate flow.

7. Styling All Cards at Once

Changing the font size, background color, or padding of every data card in a form is painful if you do it one by one. Alan Chai discovered a simple selection trick that makes it instant.

1. Click the name of your form in the Tree View to expand it.
2. Click the first data card in the Tree View.
3. Hold down the Shift key and click the last data card in the Tree View.
4. With all cards selected, change any property in the right-hand pane. The change applies to every card.

8. Copy-Paste Without the Drift

Copying a control from one data card to another is a great way to save time. Unfortunately, Power Apps has a habit of moving the pasted control to a random X and Y position. Sancho Harker's fix is a simple formula.

// Instead of: X: 30, Y: 10
X: 30 * 1
Y: 10 * 1

Because this is a formula, Power Apps treats it as a hard rule that must be kept exactly. The pasted control retains its position perfectly.

9. Building a Wizard on a Single Screen

Long forms are intimidating. Splitting a single form into a multi-page wizard is surprisingly easy. You don't need multiple screens. Instead, group your data cards into logical sections and control their visibility with a state variable.

// Page 1: Requester Information
DataCard1.Visible: locCurrentPage = 1

// Page 2: Issue Details
DataCard2.Visible: locCurrentPage = 2

// Page 3: Assignment
DataCard3.Visible: locCurrentPage = 3

// 'Next' button OnSelect
UpdateContext({locCurrentPage: locCurrentPage + 1});

// 'Back' button OnSelect
UpdateContext({locCurrentPage: locCurrentPage - 1});

10. Responsive Forms that Fit Any Screen

Hardcoding a form's width to 640 pixels breaks the moment a user opens the app on a tablet or phone. Use the Parent.Width property to let the form fill the available canvas.

// Form.Width
Parent.Width

// DataCard1.Width
Parent.Width - 40

For side-by-side layouts, divide the width by two: Parent.Width / 2 - 30. This creates a truly responsive canvas that adapts to any screen size.

Common Pitfalls and Troubleshooting

• Form.Valid returns false unexpectedly: This often happens when a text input has a default value of a single space (" "). The space is not null, so the field appears valid to Power Apps but fails a data source constraint. Use the Trim function in the card's Update property: Trim(DataCardValue.Text).
• Form.Unsaved is always false: Ensure your form is actually in an editable mode. A form in ViewForm mode will never register edits. Switch to EditForm or NewForm before attempting to check for unsaved changes.
• LastSubmit is empty: The LastSubmit property is strictly an in-memory session variable. If the app restarts, it is cleared. It only reflects the last submission from the current session.
• Wizard shows all sections at startup: Double check your variable initialization. UpdateContext({locCurrentPage: 1}) must run before the visibility formulas evaluate.

Final Thoughts

These ten patterns are the foundation of every professional form I build in Power Apps. They eliminate screen duplication, improve user experience, and significantly reduce app maintenance. Once you integrate the FormMode and Updates patterns into your workflow, you will wonder how you ever managed without them.

I challenge you to review your last Power Apps project. Find the form screens. Are they duplicated? Are the notification messages lying to the user? Pick one of these ten techniques and refactor it today. Your users will thank you.

References

• Original source material and inspiration: Matthew Devaney - 10 Things You Should Know About Power Apps Forms
• Microsoft Learn: Form Control overview (placeholder URL)
• Microsoft Learn: Using the Patch function (placeholder URL)