A model-driven app script must create a new account together with a new primary contact in one Xrm.WebApi request so that both rows are created in a single operation. How should the script do this?
Select an answer to reveal the explanation.
Short Explanation
It's like mailing a box with a smaller box packed inside: you nest the contact object right inside the account data, and Dataverse unpacks both in one trip. That's deep insert, and it's one request instead of a chain of three.
Full Explanation
Xrm.WebApi.createRecord supports deep insert: the data object for the parent row can include a single-valued navigation property, such as primarycontactid on account, whose value is an object containing the columns of the related row to create. Dataverse creates the account and the contact and links them in one operation, so either both are created or neither is. Collection-valued navigation properties can be used the same way to create several child rows at once. Creating the account, then the contact, then updating the account takes three requests and is not atomic: a failure after the first call leaves an account without a primary contact that the script must clean up. The @odata.bind annotation associates an existing row by its URI, such as /contacts(id); it cannot carry column values for a row that does not exist yet. An upsert-style updateRecord of the contact does not create a parent account, because upsert creates or updates only the row addressed by the request. Exam caveat: the navigation property names are case-sensitive and must match the single-valued navigation property, not the lookup column's display name. Operational check: run the call from the browser console, then retrieve the new account with $expand on primarycontactid to confirm the contact was created and linked.