Power Apps Form Shows Item 1 or the Wrong SharePoint Record? Fix It Safely

When a customised SharePoint form shows Item 1, a blank choice, stale values or the wrong list record, do not start by changing every card.

Those symptoms can come from different boundaries:

• the form is showing its Studio fallback record;
• SharePointIntegration is pointing custom logic at a stale selection;
• a Choice or Lookup control is displaying the wrong field from a table;
• the control's default and the card's update formula no longer match;
• SharePoint changed after Power Apps generated the card;
• the form's New, Edit, View, Save or Cancel formulas were altered.

The safe fix is a short diagnostic sequence, not a universal Value1-to-Value replacement. The previous version of this article claimed one hidden schema fault caused most cases. Microsoft does not support that claim.

Match the symptom before changing anything

Symptom	First boundary to inspect
The form shows the first list item in Power Apps Studio	The generated form Item formula can use First(...) as a Studio fallback
SharePoint opens one item but a custom label/gallery uses another	SharePointIntegration.Selected or custom variables may be stale; inspect SelectedListItemID
A Choice/Lookup control shows Item 1, blanks or codes	Choices(...), DisplayFields, SearchFields and the returned table shape
An existing value appears blank in Edit mode	Card Default and control DefaultSelectedItems
The control looks right but saves blank/wrong data	Card Update, one-versus-many selection and column type
New opens like Edit, or Cancel/Save behaves strangely	SharePointIntegration.OnNew, .OnEdit, .OnView, .OnSave, .OnCancel
The problem started after changing the SharePoint column	Refresh the data source; then compare or regenerate only the affected card

Protect the current form first

Before repairing a production form:

1. Save the current app version.
2. Export or otherwise record a recoverable copy using your normal Power Platform process.
3. Photograph or copy the affected card's formulas and advanced properties.
4. Record the SharePoint column type and settings.
5. Reproduce the problem with one known list item and a normal test user.

If the card contains intentional business logic, removing and re-adding it without a record of those formulas can cure the display while deleting the rule that made the form useful.

How a customised SharePoint form works

A SharePoint-customised form is a canvas app hosted by the list. Microsoft documents the integration through the special SharePointIntegration control.

Its generated actions normally coordinate the form lifecycle:

• OnNew calls NewForm(...);
• OnEdit calls EditForm(...);
• OnView calls ViewForm(...);
• OnSave calls SubmitForm(...);
• OnCancel calls ResetForm(...);
• the form's Item property uses the selected SharePoint record, with a fallback that lets Studio display something.

Read Microsoft's SharePoint form integration reference before replacing those formulas. A screen that looks correct in Preview can still fail when SharePoint invokes New, Edit or View.

Step 1: decide whether Item 1 is only the Studio fallback

Open the affected list item from SharePoint itself, not only with the Play button in Studio.

If SharePoint opens the correct record but Studio shows the first item, the form may simply be using its generated fallback because Studio does not have a SharePoint selection. That is not a production data error.

Prove all three modes from the list:

1. Select New and confirm the form is blank/defaulted correctly.
2. Open a known record and select Edit.
3. Open a different known record in View.

If those work, do not “fix” the fallback by hard-coding an ID or variable.

Step 2: check the selected list item

Custom logic that relies on SharePointIntegration.Selected can sometimes use a stale selection. Microsoft documents SharePointIntegration.SelectedListItemID as the more reliable identifier for relevant customisations.

A typical record lookup is:

LookUp(
    [@'Your list name'],
    ID = SharePointIntegration.SelectedListItemID
)

Use Studio to insert the real data-source name; do not type a guessed internal name.

Do not automatically replace the generated form Item formula in every app. First find which custom label, gallery, variable or component is using the stale record. Keep New mode in mind: there is no existing item ID for a new record.

Check for:

• a variable set once in OnStart or OnVisible and never refreshed;
• a gallery whose Selected item is being mistaken for the SharePoint-selected item;
• a custom component receiving the first record instead of the integration record;
• a formula that uses First(ListName) outside the generated Studio fallback;
• a hard-coded item ID left from testing.

Step 3: refresh the SharePoint data source

If a column type, choice list, lookup or field name changed after the form was created, refresh the connector's view of the list.

In Power Apps Studio:

1. Open Data.
2. Find the SharePoint list used by the form.
3. Select Refresh.
4. Save, close and reopen Studio if the field metadata still looks stale.
5. Recheck the affected card before changing formulas.

Power Fx also has a Refresh function:

Refresh([@'Your list name'])

Use that at runtime only when the app genuinely needs a fresh server copy. Adding Refresh() to every screen transition is not a substitute for repairing a damaged generated card and can add needless calls.

Step 4: inspect what Choices(...) actually returns

Microsoft documents Choices(...) as returning a table for lookup and choice columns.

A formula might look like:

Choices([@'Your list name'].'Status')

But Studio may insert an encoded/internal column reference, especially for an older lookup field. Select the field through the formula editor so Power Apps supplies the correct reference.

To diagnose the table shape:

1. Select the affected combo box.
2. Confirm its Items formula points to the intended column.
3. Temporarily inspect the formula result or bind it to a simple test gallery in a copy of the app.
4. Identify the actual text field returned for each row.
5. Match the combo box's DisplayFields and SearchFields to that field.

For many single-choice SharePoint columns the text field is Value, but do not make that a universal rule for every Choice, Lookup, Person or multi-select column. Inspect the actual table.

This is why blindly replacing Value1 with Value can make one form appear fixed and break another.

Step 5: align default, selection and update

A data card and its child control must agree about the value's shape.

For a generated card, compare these properties with a clean card for the same kind of column:

• card DataField: the SharePoint field it writes;
• card Default: normally the existing field value;
• child control DefaultSelectedItems or Default: what appears initially;
• child control Items: the available records/choices;
• card Update: what the form sends on submit;
• child control SelectMultiple: whether it returns one record or a table.

Common generated patterns include:

Parent.Default

for the child control's default, and either:

DataCardValue.Selected

or:

DataCardValue.SelectedItems

for the card update, depending on the column/control contract.

Those examples are not permission to paste them everywhere. A single-select Choice, multi-select Choice, Lookup and Person column can require different record shapes. Use a newly generated comparison card or Studio's formula suggestions to confirm the intended type.

Step 6: regenerate only the affected card when necessary

If the SharePoint schema is correct, the data source is refreshed and the affected generated card remains inconsistent:

1. Copy every intentional custom formula from that card.
2. Note its position, width and visible/required behaviour.
3. Remove the field from the form through Edit fields.
4. Add the field back.
5. Compare the regenerated formulas with the recorded ones.
6. Reapply only the business customisations you still need.
7. Test before publishing.

Regenerating one card is safer than recreating the whole form. It is also evidence: if the new card works, the problem was likely in that card's metadata or formula contract, not “Power Apps delegation”.

Step 7: restore the form lifecycle

If New, Edit, View, Save or Cancel is wrong, inspect both the SharePointIntegration properties and the form properties.

Microsoft's customise a SharePoint form guide shows the generated lifecycle. Compare your formulas with a clean test list form before restoring anything.

Also inspect:

• form DefaultMode and Item;
• form OnSuccess and OnFailure;
• any navigation inside Save/Cancel logic;
• formulas that reset variables before SubmitForm() finishes;
• required cards whose error message or Update was removed.

Keep save confirmation tied to the form's successful submission. Navigating immediately after SubmitForm() can tell the user it worked before the save has actually succeeded.

What delegation does—and does not—explain

Delegation can cause incomplete results when a nondelegable query evaluates only the first 500 records by default, or up to 2,000 when configured.

It matters when a custom gallery or lookup formula searches a large source. It does not establish a universal cause for a Choice control displaying Item 1.

If a lookup list is large, inspect the exact Filter, Search, LookUp and connector delegation support. Plant a known record beyond the local row limit and prove it can be found. Do not use a small test list as evidence that production search is complete.

Test matrix before republishing

Run the form from SharePoint with a normal user and record the result:

Test	Evidence to capture
New record	Blank/default values, valid save and created SharePoint row
Edit record A	Existing single and multi-value fields load and save
Edit record B immediately after A	No stale values from A
View record	Correct read-only record and formatting
Cancel	Unsaved values are discarded as intended
Required field empty	Useful validation; no false success
One and several choices	Correct stored shape for the column
Long/realistic lookup data	Correct display and selection
Permission-restricted user	Expected access or a useful failure
Browser refresh/reopen	Correct record after a fresh session

If the problem only occurs in a published session, use Live monitor and inspect the data operation rather than layering more variables onto the form.

Frequently asked questions

Why does my Power Apps SharePoint form show Item 1?

It may be a Studio first-record fallback, a combo box displaying the wrong field, or a stale/custom record binding. Test the form from SharePoint and inspect the exact boundary before changing formulas.

Should I change Value1 to Value?

Only if the actual Choices(...) table contains Value and the control is configured to display it. Choice, Lookup, Person and multi-select fields can return different shapes, so there is no safe universal replacement.

Why does the form open the wrong SharePoint item?

Custom logic may be using a stale selection or variable. Microsoft documents SharePointIntegration.SelectedListItemID for relevant record lookups; keep New mode and the generated form lifecycle intact.

Is Refresh enough after changing a SharePoint column?

Refresh the data source first. If one generated card is still inconsistent, preserve its custom formulas and remove/re-add that field rather than rebuilding the whole form immediately.

Why does the right choice display but save blank?

Inspect the data card's Update property and the control's one-versus-many selection shape. The displayed field and the value submitted by the form are separate contracts.

Fix the smallest broken boundary

The reliable repair is usually modest: prove the SharePoint-selected record, refresh the source, inspect the Choices(...) table, align the card and control, and regenerate only the damaged field when necessary.

If you need help reading the formula shapes without rebuilding the form, join the Power Apps Builders Space. Bring the SharePoint column type plus the card's Items, Default, DefaultSelectedItems and Update formulas.

How this article was checked

This rewrite was checked on 14 August 2026 against Microsoft's current documentation for SharePoint form integration, customising list forms, data forms, Choices(...), the combo box control and Refresh(...).