An external billing system identifies customers by a customer number that it stores in a text column on the Dataverse account table. The integration code must create, retrieve and update accounts by that customer number without first looking up the Dataverse GUID. What should the developer configure on the table?
Select an answer to reveal the explanation.
Short Explanation
An alternate key is like giving each account a second ID card that the outside world already carries. Once Dataverse builds the index behind it, your code can address rows by customer number directly. Just don't use it the minute you create it, because the index builds in the background.
Full Explanation
An alternate key declares that one or more columns uniquely identify a row, and Dataverse enforces that uniqueness with a database index. Integration code can then reference a row by the key value instead of its GUID, for example in Web API URLs, in entity references, and in upsert operations. Creating the key starts an asynchronous system job that builds the index, and the key's index status moves through pending and in progress to active; until it is active, the key cannot be relied on. Making a column required and searchable affects form validation and Dataverse search; neither lets the Web API address a row by that column. The primary name column is the display value shown in lookups and is not a unique identifier, so it cannot be used to address rows in a URL. The primary key is a GUID; a customer number such as a text value cannot be stored there, and changing identifiers that way would break every existing reference. Exam caveat: keys can only use certain column types, such as text, whole number, decimal, date and lookup columns, and a table has a limited number of keys, so design the key with the external identifier in mind. Operational check: after creating the key, confirm its index status is Active, then retrieve one account by customer number through the Web API.