Supported7 min readUpdated June 5, 2026

InfoPath source fields vs SharePoint columns

Understand why source bindings, user-facing labels, display names, and internal column names can all be different.

Quick answer

In short

InfoPath source bindings are not always the same as SharePoint display names or internal names. The generated app must save using the SharePoint internal column while showing a friendly label to the user.

Most likely cause

Confusion happens when a field label like State Conservationist maps to an internal column like StateConservationist, or when InfoPath uses a secondary-list value field behind a friendly dropdown label.

What to do next

Review the mapping row and keep source binding, target internal name, and user-facing label separate.

Four names can exist

  • Source binding: the InfoPath XML path or field name.
  • InfoPath visible label: the caption the user saw on the form.
  • SharePoint display name: the column name users see in list settings and views.
  • SharePoint internal name: the stable key Power Apps must use to save reliably.

What the generator should do

The generated Power Apps DataField and Update logic should use the SharePoint internal name. The user-facing label should use the best available InfoPath caption or friendly SharePoint display name. Changing the binding to a friendly label can break saving.

How to spot a mismatch

  • The label shown on the app is an internal-style name with no spaces.
  • A dropdown displays one value but saves another unexpected value.
  • Power Apps shows a dependency on a different list than the field name suggests.
  • The mapping row target column does not match the expected SharePoint column.

Keep reading the next most relevant guides for this form pattern.