The contact table has an active alternate key on the column named employeeid, and an integration must retrieve the contact whose employee ID is E-1042 by using the Dataverse Web API without knowing the row's GUID. Which request should the integration send?
Select an answer to reveal the explanation.
Short Explanation
Normally you put a GUID in the parentheses after the entity set. With an alternate key, you put the key name and value there instead, like name='value'. Everything else in the options is made-up syntax dressed up to look official.
Full Explanation
The Web API addresses a single row by placing its key in parentheses after the entity set name. For the primary key that is the GUID; for an alternate key the parentheses contain the key column's logical name and value, with string values in single quotes, so contacts(employeeid='E-1042') retrieves the contact through the active alternate key. Composite keys list each column and value separated by commas. The same syntax works for PATCH, DELETE and for binding lookups with an @odata.bind reference. A $key query option does not exist in the Dataverse Web API; filtering a collection uses $filter and returns a collection rather than addressing one row. Putting the bare value in parentheses tells the service to treat it as the primary key, so E-1042 is not a valid GUID and the request fails, and a $keyname option is invented. Path segments such as /employeeid/E-1042 would be read as property navigation, which does not address a row by its key. Exam caveat: the key must be active, and the column inside the parentheses must be part of a defined key; an ordinary column there produces an error. Operational check: send the request with a known employee ID, confirm one contact is returned, then repeat with a value that does not exist and confirm a not-found response.