When creating a related record in Microsoft Dynamics/Power Apps, ever notice how the “quick create” form for the new entity may be displayed with some fields prepopulated?
For example, on an account, go to related contacts and click “New Contact.” By default, the create contact form that pops up shows account, phone and address pre-filled in with data from the account. The user can leave these values untouched or edit them, at their preference, before clicking “Save” to actually create the new entity record.
If you’re working programmatically—say using the Dataverse Web API—and would like to prepopulate fields like this from another entity, how would you go about pulling this off?
You could maintain your own mappings, like “When creating a contact for an account, set fields x, y and z on the new contact to the corresponding values from the related account.” While technically valid, this requires you to own the responsibility of configuring and storing these mappings. What if, instead, you could simply use the exact same template that the Dynamics/Power Apps UI uses?
Generate a Template
Try InitializeFrom!
GET {{webApiUrl}}InitializeFrom(EntityMoniker=@p1, TargetEntityName=@p2, TargetFieldType=@p3)?@p1={'@odata.id':'accounts(b4d3f910-1896-eb11-b1ac-000d3a3ac80d)'}&@p2='contact'&@p3=Microsoft.Dynamics.CRM.TargetFieldType'ValidForCreate'
Above, three arguments are passed:
- EntityMoniker: Identifies the base record to use in initializing the new record’s template. In case, the base is the account with an ID of b4d3f910-1896-eb11-b1ac-000d3a3ac80d.
- TargetEntityName: The type of new entity template to generate. Here, a template for a new contact entity is requested.
- TargetFieldType: Controls which attributes should be used when generating the new template. Since this example is focused on creating a template to be used for a new record, “ValidForCreate” attributes are requested.
(Not used in this example: There’s also an optional “SkipParentalRelationshipMapping,” which in some cases can be used to control whether the generated template includes a link back to the parent record. If not specified, the default appears to be to include a link back.)
What’s returned is a template which can be used when creating a new record.
{
"@odata.context": "{{webApiUrl}}$metadata#contacts/$entity",
"@odata.type": "#Microsoft.Dynamics.CRM.contact",
"address1_city": "Redmond",
"address1_stateorprovince": "WA",
"telephone1": "555-0158",
"address1_postalcode": "78214",
"address1_country": "U.S.",
"address1_line1": "2137 Birchwood Dr",
"cre7c_Account@odata.bind": "accounts(b4d3f910-1896-eb11-b1ac-000d3a3ac80d)",
"parentcustomerid_account@odata.bind": "accounts(b4d3f910-1896-eb11-b1ac-000d3a3ac80d)",
"transactioncurrencyid@odata.bind": "transactioncurrencies(7a9a516a-1796-eb11-b1ac-000d3a3ac8fa)"
}
To emphasize: Despite its name, InitializeFrom does not create a new record. Instead, it simply produces a template which you can use as the basis for creating a new record. You can take what’s returned, add or modify it as desired, then pass the resulting JSON to Dataverse in the body of a normal Dataverse Web API create entity POST call. Only then will a new entity actually be created.
InitializeFrom allows you to use the same “prepopulate fields when creating a related entity” templates that Dynamics/Power Apps internally uses. Nice!
How these mappings are defined and where they are stored in the Dynamics/Power Apps/Dataverse world are topics outside the scope of this post, but for starts: When editing a relationship in the classic admin interface, in some cases you’ll be able to see the mappings that apply to that pairing of entities. Also, mappings for entities that do not have direct relationships can be accessed by querying system metadata .