web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / Customising the Contac...
Microsoft Dynamics CRM (Archived)

Customising the Contact Entity

(0) ShareShare
ReportReport
Posted on by MattTaylor 130

Hi folks,

I'm relatively new to Dynamics and am looking for some advice around creating custom information for a Contact record.

The situation is that we have a few different types of Contact and for some of these we'll need to capture more information than Dynamics has OOB. To give an example, let's say for our "Delegate" type we'll need to capture passport information (nationality, passport number, etc.) but for Contacts related to an Organisation we won't need to know that information. 

My first option is to create custom fields for everything I want to know and use Business Rules to show/hide based on a custom "Contact Type" field, but this does mean that I am ending up with potentially quite a few fields that are not used for many of the Contacts. In the days of cheap storage perhaps this isn't something to worry about but it does feel a bit messy and isn't really normalised. 

My second option is to create a custom Entity to store the additional information in and then create a relationship between that and the Contact (using Workflows to generate a new record, etc.). 

I'm quite happy with doing both of those options but I wanted to get some advice (or opinions) on what the best practice was for situations like this with Dynamics. 

For info I'm using Dynamics 365.

Kindest regards,

Matt

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Aric Levin - MVP Profile Picture
    Aric Levin - MVP 30,190 Moderator on at

    Hi Matt,

    I am not sure how different your customizations are between a regular contact and a delegate contact for example, but it is possible to have multiple forms for the Contact entity.

    The default form can be the Contact Entity, but if you are creating a delegate contact you can have the user's fill out the delegate contact form, and it will have all the additional fields.

    If the difference between your forms is minor, and only a difference of a few fields, you can definitely use Business Rules (or JavaScript), and based on a particular field (such as Contact Type), you can show or hide other fields on the form.

    I would not go with the approach of creating a separate entity for this purpose, as this is still part of the Contact entity, unless you have a relationship in there, where you need to have multiple records of the same type for a particular Contact (such as passports, where you would have a list of all the passports the customer has, but I don't think that is your case).

    If you provide us with a few more details as to the types of fields and contact types that you are trying to capture, maybe we can give you a definite answer, but I am leaning to one of the two options I gave you above.

    Hope this helps.

  • MattTaylor Profile Picture
    MattTaylor 130 on at

    Hi Aric,

    Thanks for the reply and what you've suggested makes a lot of sense. I agree that using different forms makes sense if I go down the route of just adding my custom fields to the Contact.

    I think perhaps I didn't explain the custom entity part - the intention was to still use the Contact entity and to simulate a 1:1 relationship between the Contact and Delegate (which is the custom Entity). I suppose I considered this route because I'd learnt that when designing you should try and normalise the data as much as possible and having 10-15 fields on the Contact that were only relevant to 1/2 of the records didn't feel normalised - but given how cheap storage is, perhaps that's me being fussy!

    I did read that you may want a custom Entity linked to the main Contact when you have particular security concerns (i.e. you don't want everyone to be able to see certain details) and you don't want to use field level security.

    In actual fact I am also adding Passports to Contacts and have obviously used the 1:N as you suggest above.

    For more detail:

    I only have two Contact Types at the moment (Delegate and Organisation Employee) but there's a potential to have more. The Delegate record has about 10-15 fields which include things like Workforce ID, Contract Start Date and Nationality.

    Thanks again for your reply - I think I'm moving towards just using the Contact Entity.

    Matt

  • Aric Levin - MVP Profile Picture
    Aric Levin - MVP 30,190 Moderator on at

    Hi Matt,

    I think that logic is fine.

    You can also consider using some of the existing fields in the Contact entity that are not being used by you for the delegate purpose instead of leaving them unused.

    If you actually look at the customizations of the CRM environment, there is a 1:1 relationship between User and Mailbox for example, and you can use the same type of logic if you decide to go that route.

    Good luck with this.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
SA-08121319-0 Profile Picture

SA-08121319-0 4

#1
Calum MacFarlane Profile Picture

Calum MacFarlane 4

#3
Alex Fun Wei Jie Profile Picture

Alex Fun Wei Jie 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans