But if you're pulling a large set of items, you really want to use the search index.
That's where things get weird.
The Find-Item command gives you fast results… but they aren't real Sitecore items. They're search result objects; great for speed, not so great for populating a multilist. Sitecore expects actual items, and when it doesn't get them, your field ends up looking empty.
Luckly, you don't have to abandon the approach completely. The fix is actually a pretty straightforward.
Some Context
For context, you can set the datasource for a multilist to be driven via a script in SPE like this:
In the script definition itself, you can write PowerShell to obtain some set of items from the tree. The resulting list is what shows as applicable for selection on the field.
In theory, you should be able to also utilize the Find-Item commandlet to obtain a list of items from the index. In my case was necessary due the performance implications of running a Get-ChildItem against a massive subtree.
First attempt looked something like this:
So far, so good. You get back a list of items. Or do you?
The Catch
The objects in the $list variable returned by Find-Item are not Sitecore items. They're dynamic search result objects that look like items, walk like items, but won't work in your multilist unless they quack like items.
If you try to return them as-is from your script, you'll find that, even if items were found in the index, the multilist fails to render the items for selection.
The fix? Pretty simple actuallu: Transform the search results back into legit Sitecore items.
Put it all together and you're golden
Now your multilist knows what to do. The search is lightning fast thanks to the index, and authors can pick from relevant matches without sifting through the entire tree.
Why This Matters
This pattern shines when you're working with large content trees or complex tagging structures where traditional item traversal would be painfully slow. By using the index, you're offloading the heavy lifting to Solr, gaining serious performance without sacrificing editor experience.
But more importantly, it calls out a subtle, easy-to-miss SPE gotcha: not all objects returned from PowerShell helpers are Sitecore items. If you're using Find-Item, you'll almost always need a second pass to resolve those results into actual items before they'll work in a field context.
Fail to do that, and you might spend hours wondering why your multilist is coming up empty, despite the index finding exactly what you wanted.
Happy datasourcing! 🚀
It's been 671 days since the last update to the Sitecore Icon Search web app and 1,278 days since my last update to the Chrome and Firefox extensions. I've made updates to squash new bugs across the Sitecore Icon Search ecosystem that have surfaced since the previous release while mitigating the extensions' delisting at the beginning of 2023. 
Last week, while we were all preoccupied with COVID-19, Sitecore did something nobody could have predicted.
Between the chaos, our beloved 
Last September, I wrote about 
