Need help fixing data not saving correctly in Power Apps

Apps
1

I built a Power Apps form to submit items to a SharePoint list, but some fields randomly fail to save or overwrite existing data with blanks. I’ve double‑checked the form’s Update properties and the OnSubmit formula, but I can’t find what’s wrong. What could cause this inconsistent saving behavior and how can I reliably fix it so all fields submit correctly every time

2

This is almost always about how the form is submitting or how cards are bound, not SharePoint randomly misbehaving.

Things I would check step by step:

  1. Check the DataSource and Item

    • Select the EditForm control.
    • DataSource should be your list.
    • Item should be something like:
      If(EditMode, Gallery.Selected, Defaults(YourList))
    • If Item points to the wrong record or a blank record, fields overwrite with blanks.

  2. Make sure you use SubmitForm, not Patch and SubmitForm together

    • In the button OnSelect, keep it simple:
      SubmitForm(EditForm1)
    • Remove extra Patch calls or ResetForm calls that trigger before data saves.
    • Do not wrap SubmitForm in a ResetForm before it.

  3. Check each card’s Update property

    • For TextInput cards: Update should be TextInputX.Text.
    • For Dropdowns: Update should be DropdownX.Selected or DropdownX.Selected.Value (depending on column type).
    • For Yes/No: Update should be ToggleX.Value.
    • If Update is blank or points to a control that was deleted or renamed, that field saves as blank.
    • Compare a working field and a failing field side by side.

  4. Confirm the DataField matches the column internal name

    • Select the data card.
    • Check DataField property. It must match the SharePoint column internal name, not the display name if they differ.
    • If you renamed columns in SharePoint after building the app, Power Apps sometimes keeps the old binding, then it looks random when saving.

  5. Check Required and Default in SharePoint vs Power Apps

    • In SharePoint, see if the column is Required.
    • In Power Apps, if you hide a required field or its Update returns blank, SubmitForm can behave oddly, or other fields look like they did not save.
    • For required fields you hide, set a valid Default and a static Update value.

  6. Remove or fix logic in OnSuccess and OnFailure

    • OnSuccess of the form, keep it simple while debugging:
      Notify(‘Saved’)
    • If you have logic like ResetForm(EditForm1) or Navigate to another screen too early, you might think data is not saved, or overwrites come from a second submit.

  7. Turn on Error handling and test

    • After SubmitForm(EditForm1), use:
      If(
      EditForm1.Error <> ‘’,
      Notify(EditForm1.Error, NotificationType.Error)
      )
    • This shows if SharePoint rejects some fields.

  8. Watch for concurrent edits

    • If multiple users edit the same item and your Item property always refers to Gallery.Selected, someone might be editing an older version.
    • Use Forms.Mode = FormMode.New for new items and FormMode.Edit with a specific record for edits.

Quick test to isolate:

  • Create a new screen with a new edit form bound to the same list.
  • Include only 3 or 4 fields that fail.
  • Use a simple button:
    SubmitForm(Form1)
  • If it works here, the issue is with your custom logic on the original screen.

If you post your OnSelect formula of the submit button and one example of a broken card’s Update and DataField, people can usually spot the problem fast.

3

Sounds like you’re hitting one of those “Power Apps is totally fine, you are the bug” situations.

@kakeru already covered the usual suspects (Update props, DataField, SubmitForm vs Patch), so I’ll throw in the less obvious stuff that has bitten me:

  1. Multiple forms or duplicate controls updating the same field
    Check if:

    • You have more than one EditForm bound to the same list on the screen.
    • You copied & pasted cards between forms and left both versions on the screen.
      Sometimes an “invisible” or off‑screen form/card is still submitting and writing blanks because its Update is empty.

  2. Hidden controls still driving the Update
    Example:

    • You used to have a TextInput for a column, then switched to a Dropdown, but the card’s Update is still pointing to the old TextInput (which you hid or deleted).
      Result: the card’s Update ends up blank at runtime, so SharePoint gets blanks randomly.
      Quick check: temporarily set the card’s DisplayMode to Edit and re‑insert the card from the fields pane for that column. Compare the auto‑generated Update with yours.

  3. OnVisible or OnStart logic silently overwriting fields
    Look at:

    • Screen OnVisible
    • App OnStart
      If you have something like:
    UpdateContext({varRecord: Defaults(YourList)})

    or a Reset(EditForm1) or Reset(TextInputX) firing at the wrong time, it can clear controls right before or right after SubmitForm runs.
    Debug trick: comment out all Reset(...), UpdateContext(...) and Set(...) that touch the form’s fields and test again.

  4. Use the form’s LastSubmit and Valid properties to see what actually went out
    Add a test label and set:

    Text = JSON(EditForm1.LastSubmit, JSONFormat.IndentFour)

    Submit the form and see if the “randomly blank” fields are already blank in LastSubmit.

    • If LastSubmit is blank: the issue is in the form / Update props / your logic.
    • If LastSubmit is correct but SharePoint shows blanks: then it might actually be a column type / lookup / choice mismatch or a SharePoint validation rule killing the value.

  5. Column type mismatches that “seem” to work
    A sneaky one:

    • You bind a text input directly to a Choice, Lookup, or Person column, using .Text instead of .Selected or the full record.
      Some submissions “work”, others silently fail or get wiped, especially with multi‑selects.
      For multi‑choice / multi‑lookup, make sure Update returns a table of records, not a string.

  6. Concurrency & stale records, but not in the usual way
    I kind of disagree a bit with the “random” label others use. It’s usually not random; it’s stale data.
    If you:

    • Load a record into a context variable on screen load
    • Bind the form Item to that variable and never refresh it
      Another user edits the item, your next submit can overwrite fields with whatever your local copy had (including blanks).
      Test: set Item directly to a LookUp(YourList, ID = Param('ID')) or use Refresh(YourList) before navigating into edit mode.

  7. Turn on the experimental “Formula-level error management” and log errors
    In Settings > Upcoming features > Experimental, enable formula‑level error management (if you haven’t already).
    After SubmitForm(EditForm1), check:

    If(
    !EditForm1.Valid,
    Notify(
        Concatenate(
            'Form invalid. Error: ',
            EditForm1.Error
        ),
        NotificationType.Error
    )
)

    Sometimes a validation error on one field prevents that field from saving, while others update, which feels random.

  8. Test with a completely clean, auto‑generated form
    I know people hate hearing “rebuild it,” but for debugging it’s gold:

    • New screen
    • Insert > Form > Edit form
    • Bind to same list
    • Add exactly the problem fields
    • Use default SubmitForm(Form1)
      If everything works there, your issue is not SharePoint and not the list. It’s something custom in your original screen: extra formulas, context vars, or a rogue Reset.

If you’re up for it, paste the exact OnSelect of the submit button and the full Update formula + DataField for one “randomly blank” card. Nine times out of ten, the bug is in a single weird expression you forgot you ever wrote.