Office365Users.SearchUserV2() vs Choices(SPList.PeopleColumn)

[_sigmaNot_]

Hi everyone,

I'm working on a people picker, that should allow the end user to search for users based on location, names or job titles.  From what I've read online, the O365Users connector is not currently able to do this as OfficeLocation and JobTitle are not included in the fields where searchTerm looks as per the docs.

Here's what I've tried...

1. I found this post Detailed Solution for getting all O365 users based on a searchTerm which was a really big help as I was stuck on getting more than 1000 users.  However this only works by providing a searchTerm.  I'm not sure if it should work without it, but in my case it didn't work. My org currently has over 100K users and my people picker should only be looking for about 200 users from there.

I might be able to reduce the list considerably to around 2K if searchTerm could accept a wildcard somehow or include other fields in the search like OfficeLocation or Department, however I didn't find any examples of this and have not been able to make it work.  This is what I tried that didn't work:

//Expecting it to filter out those records that don't contain the searchterm, however this isn't working
Office365Users.SearchUserV2({searchTerm:"@mydomain.com"}).value

2. Ran across this other post Difference between Choices solution and Office365Users connector which taught me about the approach of using Choices(SPList.PeopleColumn) in a searchable combo box.  This approach is easier to implement than the previous one, but still doesn't meet my requirements as this data set doesn't contain OfficeLocation, and I don't really understand how the Choices method really works.  I tried using a collection to gather the resulting data set from the Choices method, but it only gives me up to 25 results, whereas it'll search through all users when inside a combo box.

Has anyone ran into a similar use case where there's over 100K users in the tenant but end user only needs to search for users based on any of the fields that searchTerm currently doesn't support?

[_sigmaNot_ · Accepted solution]

For anyone else with a similar use case...

I ended up using Power Automate and the Azure AD connector to get the users that meet my requirements.  In part this was possible because all users that I need to collect are members in 1 of 3 automated AD groups so there's no need to do any manual maintenance on the groups 😁

Shout out to Deepak (I don't know your handle if you are a part of this community 😅) for his practical video showing the use of regex to parse a JSON string into a collection.

Send Array/JSON Response from Power Automate Flow to Power Apps #PowerApps #PowerAutomate #Response ...

[v-jefferni]

Hi @_sigmaNot_ ,

We usually use Power Automate and Office 365 Users connector to get users in a large organization, then return the array to PowerApps use the method in the link. Why not use Azure AD connector? Because there are limitations:

Azure AD - Connectors | Microsoft Learn

To use the Azure AD connector, the account needs to have the following administrator permissions:

• Group.ReadWrite.All
• User.ReadWrite.All
• Directory.ReadWrite.All

Best regards,

[_sigmaNot_]

Hi @v-jefferni, I didn't know about these limitations.  Thank you for sharing.

During my initial search before landing on the Azure AD connector approach I ran across the post below which uses the O365Users connector.  Unless I'm misunderstanding, it shares the same limitations as the PowerApps connector where searchTerm only looks in some of the fields, which unfortunately do not include the ones that I need to filter such a large user list in my case.

Solved: Get all users through Office 365 Users connector t... - Power Platform Community (microsoft....

I see the solution to the post was enabling the Pagination option, however I fear this may have worse performance compared to the Azure AD connector approach.  I did not try using the O365Users connector in Power Automate so this is just my deduction when looking at loading 100K users and then filter based on criteria, as opposed to loading the exact number of users needed which make up 100% of the 3 groups I mentioned (240 users total).

Does my deduction make sense, or am I way off? 😅