Builder review8 min readUpdated June 5, 2026

Prepare secondary-list-backed dropdowns

Make dropdowns work when InfoPath read choices from a supporting SharePoint list instead of static option values.

Quick answer

In short

Secondary-list dropdowns need a resolved supporting SharePoint list, a display column, a saved value column, and at least one row that matches any filter logic.

Most likely cause

If clicking the dropdown arrow does nothing, the Items formula is usually empty or erroring because the supporting list is missing, empty, filtered to zero rows, or mapped to the wrong list.

What to do next

Confirm the supporting target is resolved, the list has rows, the generated Items formula points at the right list, and the dropdown Value property uses the display label field.

What the generator needs

  • The source InfoPath data connection name.
  • The destination SharePoint list/library ID and URL.
  • The display column users should see, such as Title or Name.
  • The value column the form should save, such as email, code, or ID.
  • Any filter condition from the original form, such as a role or status.

Common symptoms

  • The dropdown chevron appears but the list never opens.
  • The property panel shows Depends on a different list than expected.
  • A dropdown shows one test value but not the production rows.
  • A selected value displays correctly but saves the display name instead of the intended value.

Debug checklist in Power Apps Studio

  1. Select the dropdown control.
  2. Check Items and confirm the SharePoint list name is correct.
  3. Check Value and confirm it points at the display label field.
  4. Temporarily remove filters from Items to see whether the list returns rows.
  5. Check the parent card Update formula and confirm it saves Selected.Value or the intended saved column.

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