A code component on a model-driven form must let users choose one or more existing contacts using the standard Dataverse lookup experience, with the same search and recent items that users see elsewhere in the app. Which framework API should the component call?
Select an answer to reveal the explanation.
Short Explanation
Why build your own picker when the platform will lend you its own? lookupObjects pops the standard lookup dialog, so your users get the search and recent items they already know, and you get back the records they picked.
Full Explanation
The Utility API in the component framework, available through context.utils, includes lookupObjects, which opens the platform lookup dialog. The component passes lookup options such as the allowed table types, whether multiple selection is allowed, the default view and filters, and the method returns a promise that resolves to the selected records with their IDs, names and table types. Using the platform dialog gives users consistent search, recent items and views, and it respects their security permissions without extra code. Building a custom drop-down from Web API results is possible, but it duplicates the lookup experience, loses recent items and views, and must reimplement search and paging, which is the opposite of the requirement. openForm opens a record form for creating or editing a record; it is not a selection dialog, and reading a selection from a saved form would create or modify rows instead of choosing existing ones. pickFile belongs to the Device API and selects files from the device; it has nothing to do with Dataverse records. Exam caveat: lookupObjects returns the selection to the component, which must then store it, for example through a bound property or a Web API association. Operational check: open the form, invoke the component's selection control, confirm the standard lookup dialog appears for contacts, and confirm the chosen contacts are returned.