Power Apps Dropdown Control With a SharePoint List (Step by Step)

The first time I built a leave request app for a small HR team, I let people type the leave type and department into ordinary text boxes. Within a week, the SharePoint list had “Sick”, “Sick leave”, “sick lv” and “HR”, “Hr” and “Human Resources”, and none of the reports added up.

The fix was to replace those text boxes with dropdowns whose options come from a SharePoint list, so everyone picks from exactly the same values.

I’ve used this pattern in many apps since. It keeps the data clean, it’s easier for people to fill in, and when the options change, you update one list instead of the app.

Quick answer: Add a Dropdown control, set its Items property to your SharePoint list (for example 'Leave Types') and its ItemDisplayText to ThisItem.Title. Read the choice with ddlLeaveType.Selected.Title, and save it through a form’s Update property or with Patch(). With the classic dropdown, set the Value property to the column instead of ItemDisplayText.

In this tutorial, I’ll walk you through the whole setup with that leave request app: the SharePoint list for the options, binding the dropdown, saving the selection, default values, cascading dropdowns and the problems that come up most often.

Classic or modern dropdown?

Power Apps currently has two dropdown controls, and they use different property names, which is the cause of a lot of confusion. The screenshots in this tutorial use the modern Dropdown, which is still labelled as a preview control. It uses ItemDisplayText to choose the text people see and Default (a record) for the starting value (modern Dropdown reference).

The classic Drop down is still available and fully supported. It uses the Value property to choose which column to show and Default as text, and it shows a maximum of 500 items (classic Drop down reference). I’ll point out the classic equivalent wherever the two differ.

Step 1: Create a SharePoint list for the dropdown options

For the leave type dropdown, I keep the options in their own SharePoint list called Leave Types. It needs just a few columns: Title (single line of text) for the name of the leave type, IsActive (Yes/No) so you can retire an option without deleting it, and optionally SortOrder (Number) to control the order in the dropdown.

A separate list has a few advantages over typing the options into the app. The main LeaveRequests list stays clean, the same options can be reused in other apps, and an HR admin can add or retire a leave type without anyone opening Power Apps Studio.

In the list that stores the requests, I use a single line of text column for the leave type. Microsoft’s dependent drop-down guidance recommends the same, because text columns avoid delegation problems. You can use a Choice column instead if you want SharePoint to validate the values as well; I cover the difference when we save the value.

Step 2: Add SharePoint as a data source

Open your canvas app in Power Apps Studio. In the left pane, select Data, then Add data, search for SharePoint, connect to your site, and select the Leave Types list. Add the LeaveRequests list as well if it isn’t there yet.

Step 3: Insert the dropdown and bind it to the list

Go to Insert, search for Dropdown, and add it to the screen. Rename it straight away to something meaningful, such as ddlLeaveType. It seems minor, but clear names make every formula later on much easier to read.

Now select the dropdown and set its Items property to the list:

'Leave Types'

Then tell the dropdown which column to show by setting ItemDisplayText to the Title column:

ThisItem.Title

When you play the app and open the dropdown, you’ll see each leave type from the list:

With the classic Drop down, you’d set its Value property to "Title" instead of using ItemDisplayText.

In practice, you usually want to hide retired options and control the order. This formula does both, and both parts are delegable to SharePoint, so it keeps working as the list grows:

SortByColumns(
    Filter('Leave Types', IsActive = true),
    "SortOrder",
    SortOrder.Ascending
)

Step 4: Save the selected value to SharePoint

Showing the options is only half the job; the selection also has to be saved in the LeaveRequests list. The easiest way is an Edit form. Insert one from Insert > Edit form, set its data source to LeaveRequests, and make sure the LeaveType field is on the form.

Unlock the LeaveType card, delete the text input inside it, and put your ddlLeaveType dropdown in the card instead. Then set the card’s Update property, which decides what’s saved, to:

ddlLeaveType.Selected.Title

Selected is the whole record for the chosen leave type, and .Title takes the text from it, which is exactly what a single line of text column expects. If LeaveType is a Choice column, SharePoint expects a record instead, so use {Value: ddlLeaveType.Selected.Title}.

Finally, set the OnSelect of your Submit button to SubmitForm(frmLeaveRequest). For a refresher on forms, see how to create a form in Power Apps.

Saving with Patch instead of a form

Sometimes a form doesn’t fit the design, for example when you’ve built a custom layout from separate controls. In that case, write the record yourself with Patch(). Defaults(LeaveRequests) tells Power Apps to create a new item, and the record lists the columns to fill in, including the dropdown value:

Patch(
    LeaveRequests,
    Defaults(LeaveRequests),
    {
        Title: txtRequestTitle.Value,
        LeaveType: ddlLeaveType.Selected.Title,
        StartDate: dpStartDate.SelectedDate,
        EndDate: dpEndDate.SelectedDate
    }
)

As with the form, send {Value: ddlLeaveType.Selected.Title} if LeaveType is a Choice column.

Step 5: Set a default value

On the modern Dropdown, the Default property expects a record from the Items table, not just text. To pre-select Casual Leave, look up that record in the list:

LookUp('Leave Types', Title = "Casual Leave")

On the classic Drop down, Default is plain text, so "Casual Leave" is enough.

You can make the default depend on the user as well. Just remember to return a record on the modern control, for example LookUp('Leave Types', Title = If(User().Email = "hr.admin@contoso.com", "Compensatory Off", "Annual Leave")).

Step 6: Show the saved value when editing a request

When someone opens an existing request, the dropdown should show the leave type that was saved, not the default. Inside the form, the card’s Parent.Default holds the saved text, so look up the matching record from it, and only use your default for new requests:

If(
    frmLeaveRequest.Mode = FormMode.New,
    LookUp('Leave Types', Title = "Annual Leave"),
    LookUp('Leave Types', Title = Parent.Default)
)

If you see an error such as “Expected record value” here, the dropdown is getting text where it needs a record, or the other way round. That’s the most common dropdown error, and this guide to dropdown values not showing covers the other causes too.

Step 7: Build a cascading dropdown

In real apps, one dropdown often depends on another. In the leave app, I wanted the Manager dropdown to show only the managers of the department picked in the Department dropdown.

For this, I use a Departments list with a Title column, and a Managers list with a Title column for the manager’s name and a Department column, again as single line of text. Add a dropdown called ddlDepartment with Items set to Departments and ItemDisplayText set to ThisItem.Title. Then add a second dropdown, ddlManager, with ItemDisplayText ThisItem.Title and this Items formula:

Filter(Managers, Department = ddlDepartment.Selected.Title)

Whenever someone changes the department, the manager list updates straight away. I always test this with a department that has no managers, because that’s where you find blank or confusing behaviour. For more on this pattern, including the classic Depends on option, see the Power Apps cascading dropdown tutorial and Microsoft’s dependent drop-down lists article.

Dropdown values not showing? Check these

If the dropdown opens empty, start with the Items property: it should point at the right list, and any Filter shouldn’t exclude every row. Then check the display setting. On the modern control, ItemDisplayText must refer to a real column, such as ThisItem.Title; on the classic control, the Value property must match a column name. Also make sure the person using the app has at least read permission on the SharePoint list.

If some values are missing rather than all of them, think about limits. The classic Drop down shows a maximum of 500 items. And formulas that can’t be delegated to SharePoint, such as Distinct() or Choices(), only look at the first 500 rows by default (you can raise the data row limit to 2,000 in Settings). Microsoft lists which functions delegate in its SharePoint connector article.

Duplicate values in the list are a separate problem: see how to remove duplicates in a Power Apps dropdown.

Tips from real projects

Plan the SharePoint lists before you build the app. Consistent column types and a separate list for options save hours of fixing formulas later. Give controls clear names like ddlLeaveType and frmLeaveRequest, and keep option lists short: a dropdown with hundreds of entries is slow to use, and a combo box with search is usually a better choice there.

Finally, decide what should happen when a filter returns nothing. Disabling the Submit button until a value is chosen is often the simplest answer, and the DisplayMode property makes that easy.

These Power Apps dropdown and combo box guides go well with this one:

• How to Create Cascading Dropdown in Power Apps? [Step By step]
• Power Apps Dropdown Values Not Showing [How to Overcome]
• Power Apps Dropdown Blank Values – A Practical Guide
• Remove Duplicates in Power Apps Dropdown [With Different Scenarios]
• Power Apps Combo Box Vs Dropdown [Know the Differences]
• How to Validate Power Apps Dropdown Control?

Frequently Asked Questions