There are situations where data from a parent entity is needed on the form for the child record. For example, there may be the need to presenting Account information on the Contact form beyond simply showing the Account lookup field. Or in Field Service displaying a series of fields from the Customer Asset record on the Work Order form. The great news is Dynamics 365 provides are several methods to accomplish this, each with unique different behaviors:
1. Quick View Forms: These ‘forms-within-a-form’ present multiple fields from the parent entity on the child record form without actually storing the fields on the child record. Quick View Forms display the current values of the source field(s), so if the field values have changed on the parent record since the child record was created, the quick view fields will present the most up-to-date information whenever the child record is opened. One thing to consider is that the fields are not stored at the child record-level, thus any searching on the field would need to be done by referencing the fields from the parent entity.
2. Use Calculated Fields: Calculated fields can be used to display most any type of field from the parent except lookup fields. An additional benefit is the ability to concatenate the text from 2 different source fields from the parent record into a single text field on the child entity. Like the quick view form, calculated fields will display the current values of the source field(s). The fields are stored at the child level, so any searching on the field can be done directly at the child entity level. Beyond the searching requirements, one consideration between using a Quick View Form vs. Calculated fields is the number of parent fields to show on the child record. If many fields are presented a quick view form may be the answer, but if only a single field is presented then creating a single calculated field may be more viable.
3. Map Parent Fields to the Child: Another option is to create duplicate fields on the child entity and map from the parent to the child in the Relationship Mapping. This will display whatever value was populated on the child from the parent at the time the child field was populated. The big consideration here is that if the value of the field changes on the parent field after the child field was populated, the value will not update on the child (i.e. the value on the child is static). This could be good or bad considering your requirements. Finally, the fields are stored at the child level, so any searching on the field can be done directly at the child entity level.
Below is a table which summarizes the behavior of each of the configuration options based on several criteria.
*Data Mapping will populate the mapped fields if the child record is created from the parent form, however, additional logic (Workflow, other) will be needed in order to populate the child’s fields if the child record is created directly as a new record.
As shown, each of these methods have unique qualities and behaviors, some which may be good or bad depending on the requirement you are trying to fulfill. The good news is that there are multiple options available, so one of these methods may meet your needs for requirement A, another method may be just what you are needing for requirement B, and a combination of a couple of these methods may provide the perfect recipe for requirement C.
Happy configuring! Contact us today.
Subscribe to our blog and never miss a post
Join our growing community of professionals and get insights, resources, and tips in your inbox weekly.