Full-Directory People Picker: A Power Apps Delegation Workaround

Building a people picker that shows everyone in a large organization is one of Power Apps’ classic delegation challenges. The built-in Choices function can only retrieve the first 500 (or up to 2,000) records, which is fine for small companies but fails when your directory swells into the tens of thousands. Fortunately, the Office 365 Users connector offers a search‑based approach that circumvents this limit entirely. In this guide, you’ll learn how to assemble a fully searchable people picker that can find any employee, no matter how many rows sit behind the scenes.

Understanding the Delegation Wall

Power Apps uses delegation to push data operations back to the source system. When a control like a combo box tries to populate from a SharePoint person column via Choices(), it can only request a limited number of records. The default ceiling is 500; even after increasing it to the maximum of 2,000, large enterprises will still see an incomplete list. That means an employee named Zara at the end of the alphabet may never appear unless you type her exact name—and even then, if the search isn’t delegated, it might not find her.

A Real‑World Scenario: Equipment Request App

Your organization’s HR department wants a simple Power App where hiring managers order equipment for new joiners. The form includes a combo box to select the employee, a dropdown for the device type, and a multi‑line notes field. The SharePoint list that holds these requests is called TeamGearRequests.

SharePoint List Columns

Building the App Interface

1. Open Power Apps and create a blank canvas app.
2. Add a data connection to the TeamGearRequests list.
3. Insert an Edit form control and set its DataSource property to the list.
4. Change DefaultMode to FormMode.New so that the form always starts ready to create a new record.
5. Rename the form and its data cards for clarity.

The Default Combo Box and Its Limit

When the form generates, the person field’s combo box automatically uses Choices(RequestedEmployee) in its Items property. As discussed, that only retrieves the top 2,000 users. To see the full directory, we need to replace that expression.

The Workaround: Switch to Office 365 Users Search

The Office 365 Users connector provides a SearchUserV2 operation that queries Microsoft Graph searching across the entire directory. Even though the operation accepts a top parameter, the search itself scans all users—you’ll always get the most relevant results regardless of total user count.

Add the Connector and Rewire the Combo Box

1. Add the Office 365 Users connector to your app (use the “Add data source” pane).
2. Select the combo box inside the person data card.
3. Replace its Items property with:

Office365Users.SearchUserV2(
  {
      searchTerm: ComboBox1.SearchText,
      top: 50,
      isSearchTermRequired: false
  }
)

The searchTerm captures what the user types, top limits the returned rows to 50 (you rarely need more displayed at once), and isSearchTermRequired: false ensures results appear when the dropdown is first opened.

Configure Display and Search Fields

• Set DisplayFields to ["DisplayName", "Mail"] – this shows the user’s full name and email in the dropdown.
• Set SearchFields to the same array – this allows searching by either name or email.

["DisplayName","Mail"]

["DisplayName","Mail"]

Polish the Combo Box Appearance

• Change InputTextPlaceholder to "Find people".
• Optionally adjust Width and Height to match your form’s layout.

Bridging the Schema: Update the Card’s Update Property

When you swap the combo box’s data source, the record shape changes from a SharePoint person type to an Office 365 user record. The parent form still expects the original schema, so you must manually construct the correct format in the card’s Update property.

Select the card (not the combo box) and set its Update property to:

{
  '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
  Claims: "i:0#.f|membership|" & ComboBox1.Selected.Mail,
  Department: "",
  DisplayName: ComboBox1.Selected.DisplayName,
  Email: ComboBox1.Selected.Mail,
  JobTitle: "",
  Picture: ""
}

This ensures the submitted data matches what SharePoint expects for a Person or Group column.

Adding Submission Logic

Insert a Button control below the form and set its Text to "Submit Request". In its OnSelect:

SubmitForm(Form1)

Now configure the form’s OnSuccess and OnFailure properties.

OnSuccess – store the newly submitted record and notify the user:

Set(varSubmittedRecord, Form1.LastSubmit);
Notify("Request submitted successfully", NotificationType.Success);
ViewForm(Form1);

Set the form’s Item property to varSubmittedRecord so it displays the record just created after submission.

OnFailure – inform the user something went wrong:

Notify("Submission failed. Please try again.", NotificationType.Error);

Testing the Solution

1. Run the app and click the people picker’s drop‑down arrow. You should see a list of names populated from the Office 365 directory.
2. If the employee you want is not on the first screen, start typing their name. The list will filter to matching users.
3. Select an employee, choose a gear type, add any notes, and submit.
4. Open the TeamGearRequests SharePoint list to confirm the new item appears with the correct person entry.

Common Mistakes & Troubleshooting

• isSearchTermRequired set to true – If the list appears empty when you open the dropdown, change this to false.
• Update property omitted – The form will try to pass the Office 365 user object directly, causing a blank person field or an error. Always override the card’s Update property.
• Top parameter too low – A value like 5 may show too few initial results. Stick with 50 unless you have a reason to change it.
• Connector permissions – The Office 365 Users connector requires appropriate Graph permissions. If you see an error on the combo box, check that the app has been granted consent to read user profiles (this is usually auto‑granted, but some tenants require admin approval).
• Slow initial load – The SearchUserV2 operation can take a moment on first call because it hits the Graph API. Caching or using a non‑delegated fallback for small lists can help, but for large directories the trade‑off is acceptable.

Performance & Security Notes

• SearchUserV2 runs server‑side; only the top N results are transmitted to the app, keeping bandwidth low.
• The search is case‑insensitive and works on both DisplayName and Mail when those fields are included in SearchFields.
• API rate limits apply to the Office 365 Users connector. For apps with heavy usage, consider adding a short delay between searches or caching common results.
• The connector respects Azure AD security boundaries – users see only the directory information they would normally have access to.

Final Recommendation

Replacing the default Choices function with Office365Users.SearchUserV2 is a clean, supported way to create a people picker that works at any scale. It is especially valuable for large enterprises where the 2,000‑record limit is a daily obstacle. The trade‑off is a slight dependency on the Office 365 Users connector, but the benefits far outweigh the configuration overhead. Use this pattern whenever you need to guarantee that no employee is left out of your people picker.

References

• Matthew Devaney, “Power Apps People Picker Delegation Workaround”, December 2022. https://www.matthewdevaney.com/power-apps-people-picker-delegation-workaround/
• Microsoft Learn, “Delegation overview for canvas apps”. https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/delegation-overview
• Microsoft Learn, “Office 365 Users connector reference”. https://learn.microsoft.com/en-us/connectors/office365users/
• Microsoft Learn, “Choices function”. https://learn.microsoft.com/en-us/power-platform/power-fx/reference/function-choices