When a Power Apps Form Will Not Submit

A Power Apps form that will not submit gives you almost nothing to work with. The button does nothing, or an error appears that names a field the user never touched, or the record saves with fields silently empty.

Almost all of it comes down to a handful of causes. Working through them in order is faster than guessing.

Start by seeing the actual error

Before anything else, make the error visible. Most apps swallow it.

// On the submit button
SubmitForm(EditForm1)

// On the form's OnFailure — this is what tells you what really happened
Notify(
    "Save failed: " & EditForm1.Error,
    NotificationType.Error
)

Form.Error carries the message the data source returned, and Form.ErrorKind carries a typed reason. Surfacing them turns a guessing exercise into a specific fix, and it is worth having in every app permanently rather than adding it during an incident.

The seven causes, in the order to check them

1. A required field is empty — including one that is not visible

The most common cause by a distance. SubmitForm validates every card in the form, not only the ones on screen. A required column whose card was hidden — or moved off the visible area during layout work — blocks submission with no obvious cause.

// Shows exactly which cards are unfilled
Concat(
    Filter(EditForm1.Updates, false),  // placeholder to keep the formula valid
    "",
    ""
);

// Practical check: set a label's Text to this while debugging
EditForm1.Error & " | " & EditForm1.ErrorKind

The reliable fix is to set unused cards' Required to false rather than hiding them, or to remove them from the form entirely.

2. The data card is not writing back

A card's Update property is what actually gets submitted. Replacing the default control inside a card without repointing Update at the new control means the field submits its original value, or blank.

This produces the specific symptom of a record that saves successfully with a field mysteriously empty.

3. Data type mismatch

A text input bound to a number column, a text value written to a choice column, or a date field receiving a string. SharePoint choice and lookup columns are the usual culprits, because they need a record rather than a value:

// Choice column — needs a record, not a string
{ Value: Dropdown1.Selected.Value }

// Lookup column
{ Id: Dropdown1.Selected.ID, Value: Dropdown1.Selected.Title }

// Person column
{
    Claims: "i:0#.f|membership|" & PeoplePicker.Selected.Email,
    DisplayName: PeoplePicker.Selected.DisplayName,
    Email: PeoplePicker.Selected.Email
}

4. Permissions

The app opens because the user can read the list. Saving needs Contribute. This produces a form that works perfectly for the maker and fails for everyone else — which is why testing as a non-privileged user is not optional.

5. Column-level constraints in the data source

Validation configured on the list itself rejects the write regardless of what the app allows: a column validation formula, a required column not on the form, or a uniqueness constraint. The error surfaces in Form.Error, which is the argument for showing it.

6. The form has no item to update

SubmitForm on a form in Edit mode with no Item set has nothing to write to. This usually happens when a gallery selection is expected but the gallery is empty, or navigation reached the screen directly.

// Guard the mode explicitly
If(
    IsBlank(Gallery1.Selected),
    NewForm(EditForm1),
    EditForm(EditForm1)
)

7. Attachment and file size limits

Attachments are submitted with the item, and a large one can push the request past the acceptable size. The symptom is a form that submits fine until someone attaches something substantial.

A pattern that prevents most of this

Rather than calling SubmitForm directly, gate it and handle both outcomes:

// Submit button OnSelect
If(
    EditForm1.Valid,
    SubmitForm(EditForm1),
    Notify("Please complete the highlighted fields.", NotificationType.Warning)
);

// Form OnSuccess
Notify("Saved.", NotificationType.Success);
Navigate(BrowseScreen, ScreenTransition.Fade);

// Form OnFailure
Notify("Save failed: " & EditForm1.Error, NotificationType.Error)

Form.Valid checks required fields before the round trip, so the user gets immediate feedback rather than a server error. And separating OnSuccess from OnFailure stops the app navigating away from a form that did not save — a bug that silently loses the user's work.

Common mistakes and better practice

• Navigating in OnSelect after SubmitForm. Submission is asynchronous; the navigation runs whether or not it saved. Navigate in OnSuccess.
• Hiding required cards instead of unsetting Required. Validation still applies to hidden cards.
• Not surfacing Form.Error. The information you need is already there.
• Testing only as the maker. Permission failures only appear for other users.
• Writing a string to a choice column. Choice, lookup and person columns need records.
• Replacing a card's control without updating Update. Produces silent blank fields.
• Using Patch to work around a form problem. Patch bypasses form validation, which turns a visible failure into a silent one.

Troubleshooting reference

Symptom	Likely cause	Fix
Button does nothing at all	Required field unfilled, possibly hidden	Check Form.Valid; unset Required on unused cards
Saves, but one field is empty	Card Update not repointed after a control change	Set Update to the new control's value
Works for the maker, fails for users	Contribute permission missing	Grant list permissions, not just app sharing
Error naming a column not on the form	List-level validation or a required column	Check list settings and column validation
Fails only with attachments	Attachment size	Reduce the file, or store it separately and link
Choice column rejected	String submitted where a record is expected	Use { Value: ... }
App navigates away but nothing saved	Navigation in OnSelect	Move it to OnSuccess

Frequently asked questions

Why does the submit button do nothing?

Usually a required field that is not visible. SubmitForm validates every card, including hidden ones.

How do I see the real error?

Display Form.Error in OnFailure. Without it, the app discards the only useful information available.

Should I use Patch instead?

Not to avoid a form problem. Patch skips form validation, so the failure becomes silent rather than fixed. Use it when you genuinely need to write without a form.

Why does it work for me but not for my users?

Sharing the app does not grant data access. Users need Contribute on the underlying list.

How do I write to a person column?

As a record containing Claims, DisplayName and Email. A plain email string is rejected.

The habit worth adopting

Put Notify(Form.Error) in OnFailure on every form you build, and leave it there. It costs one line, and it converts the entire class of "the form just does not save" problems into a specific message naming the actual cause.