Check out the latest Customer Service updates!Learn about the key capabilities and features of Dynamics 365 Customer Service and experience some of the new features.
Download overview guide | Watch Customer Service video
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Hi, I understand there is one similar post in 2015 by Mohyideen .
1) The question is can a field in one entity be used in another entity's form without a new field creation?
2) Can a look up field be used without a new field creation?
Take for e.g. Identification card number or name.
If I have these two fields in Contact, do I need to create new fields in my custom entity say "Therapy session" and "Medical assessment"?
Can I reuse the field (name or IC) or even do a look up to these fields without creating new fields?
No global field can be shared between different entities.
You have to create the same field on each entity. You could use relationship mapping between yours two entities.
This allows an entity's field to automatically copy the value of another mapped entity field. You don't need to manually assign values.
You can refer to this post and this article.
Go to Settings > Customizations > Customize the System > Components > Entities.
Select the entities to map and click 1:N Relationships, then click New 1-to-Many Relationship.
Enter the mapping properties in the new window. Save. Then click Mappings, then click New.
Select the fields you want to map.
Don't forget to publish it after saving.
Hope this helps.
If your Contact field is available in the Therapy Session and Medical Assessment, you can create a quick view for the Contact entity fields that you want to display in the other entities.
The you would go to the Form editor of the other entities (Therapy Session and Medical Assessment), and insert the Quick View where you want them.
This will allow that data to be displayed in those forms.
You will only be able to make changes to the data though from the Contact form.
Hi Lu Hao Thank you.
1) is there an official source that confirm
No global field can be shared between different entities and the same field has to be recreated on each entity? Reason because I have difficulty justifying this point to my team when the vendor claim we can create just one field from the same database source & use it on different forms.
2) is this copying of fields an automatic out of box function or need script? Reason because sometimes we get orphan records when the fields dont get copied after clicking save.
3) lastly, how many fields can we map per entity? For e.g every transaction records has at least an IC number and name. That will be two fields needed to identify & be saved with this transactional records.
Once again thank you very much.
1) Please note that form is also a child of entity. Fields can be shared in different forms, limited to forms in the same entity. It cannot be shared in different entity forms.
E.g. Email is a field of Contact entity that can be in the form called "Contact" or in the form called "Contact - Mobile". Forms can only belong to Contact entity.
(The same contact displays the same email on both the web and the mobile phone.)
If you want to display A entity field in B entity form, you can use Quick View. But this way only shows the value of A entity field, this field belongs to A entity and does not belong to B entity.
E.g. In the form of Contact entity, you can see Quick View of Opportunity and Case, but the fields in Quick View belong to Opportunity and Case, not belong to Contact entity. This is just a representation of other entities, for easy viewing.
Sorry, I didn't find the official source. If I find it, I will reply again.
2) Copying of fields is OOB function. If the copy is sometimes invalid, please check:
The following rules show what kinds of data can be mapped.
Both fields must be of the same type and the same format.
The length of the target field must be equal to or greater than the length of the source field.
The target field can’t be mapped to another field already.
The source field must be visible on the form.
The target field must be a field that a user can enter data into.
If the fields are option sets, the integer values for each option should be identical.
Address ID values can’t be mapped.
In addition, you could use workflows. You could build workflows that will update related records when fields change. So if you want to update a parent Account when you change a Contact, workflows can do that. However, they don't go from the parent down to the child out of the box. You'll need a custom workflow step if you want to update all your child records whenever a parent record is updated. You could refer to this article.
In fact, technically, the available methods are far more than these, such as using plug-ins and so on.
Try to see if Global Options Sets also meets your needs.
3) There should be no limit to the number of fields each entity can map.
Hi Colinkgl, what Lu Hao is recommending is absolutely accurate.
One clarification for you #2. When mapping fields based on a 1:N relationship, the ONLY TIME those mappings occur is when the record is created from the parent (the 1 in the relationship). For example a Contact has many Case records related to it. If you mapped phone number and name to come across to the case, this mapping would only occur when a user creates a case from the Contact record through the related records "Cases" in the navigation at the top. Only then is the mapping activated. Very frustrating it is limited in this fashion.
My preference is the quick view form if the data does not need to exist on the child entity. That way when a lookup is populated the form appears embedded on the child entity form seamlessly but those fields are read only, and they can't be referenced in a view, or reporting for that entity because they are on the Contact record not the Case (for example).
Again Lu Hao is right there are several ways to skin this, Business Rules work great, or if you only need options then you can use a global option set, but even then you still need to create a field on each entity that references that global option set.
Beware, D365 is a platform, not a simple relational database that plays by old rules or workarounds. Get to the bottom of the business need and you will find the easiest answer.
Business Applications communities