Relationship between Opp to acct or contact2

Understanding Microsoft Dynamics CRM 2013 Opportunity relationship to Account and Contact records

Microsoft Dynamics CRM 2013 Opportunity record association to parent record (Account or Contact) is based on “Potential Customer” field.  

In the past, by default, Microsoft Dynamics CRM opportunity record only had “Potential Customer” field to map the opportunity record to the parent record whether that was an account or a contact.  The “Potential Customer” field was a unique lookup field that allowed the user to select either an account or a contact record.

In the enhanced Microsoft Dynamics CRM 2013 UI, the “Potential Customer” field has been removed by default from the “Opportunity” form (still available in the entity) and instead Microsoft explicitly introduced “Account” and “Contact” lookup field in the Opportunity form. This is a very useful enhancement in the latest Microsoft Dynamics CRM 2013 (in the past, this was only available via additional customization).  This approach now enables opportunity record to track both account and contact information/relationship; however, there is one limitation which I will elaborate here.

Here’s how it works.  When you populate account or contact field in the opportunity record, the Microsoft Dynamics CRM 2013 automatically populates the “Potential Customer” field in the background. Although the “Potential Customer” field has been removed from the form, this field is very much necessary field (required field in the background). Below is a mapping of what happens.

When an opportunity record is created, the “Potential Customer” field is auto populated by the Microsoft Dynamics CRM 2013 in the background. For example, when account and contact fields are both populated, then “Potential Customer” is populated with account name; however, when only contact field is populated then the “Potential Customer” is populated with the contact name. While this seems obvious, there’s one exception. If you try to update an opportunity record and remove account field and instead associate the opportunity to a contact, then you will receive an error message (see #1 below).   (Note:  Not sure if this is as designed or if it needs to be fixed by Microsoft.)  All other combination of populating Account and Contact fields works in the opportunity record.

Note that Potential Customer field always get populated with either account or contact data. Furthermore, the system will always select account to populate Potential Customer field if both account and contact fields are populated. (UPDATE: 8/1/14: If opportunity is created from contact record, then Potential Customer field is populated with contact name even if both account and contact fields are populated upon opportunity record creation.  I don’t like how this behaves but that’s how it is at this time.  The table below does not reflect this exception scenario.)


# Account Contact Potential Customer     Account Contact Potential Customer
1 New Record A A –> Update Record B Error occurs. Record Not updated
2.1 New Record B B –> Update Record A A
2.2 A B A
3.1 New Record A B A –> Update Record B B
3.2 A A


If you need the users to be able to perform this option, then you will need to create custom jscript or PBL to update the “Potential Customer” field behind the scene.  If you use PBL, you will need to insert the Potential Customer field on the form. Also note that once you insert the Potential Customer field on the form, you will not be able to remove it but you will be able to hide it.

Here’s two simple PBLs (currently PBL does not support OR function) you will need to create to handle the scenario 1.  (note: there are 3rd party add-on tools that does OR and more complex functions.)  First PBL will always set the Potential Customer to account name, if account field is populated.  The second PBL will set Potential Customer to Contact name if account field is blank.

PBL - Set Potential Customer to Account








PBL - Set Potential Customer to Contact







Having a good understanding of how Microsoft Dynamics CRM 2013 works behind the scene and applying those knowledge to end users will help improve the usage of the Microsoft Dynamics CRM 2013 application and overall user adoption.  Hope this helps!

Leave a comment

Your email address will not be published. Required fields are marked *

5 thoughts on “Understanding Microsoft Dynamics CRM 2013 Opportunity relationship to Account and Contact records

  • Costin

    Thanks, Jonathan. I should have red your article before inserting the Potential Customer field in the form! I am stack with it now!

  • Nick

    This article is very helpful. When We install CRM 2013 fresh system, potentialCustomer(CustomerID) field is not on the form, but it is part of entity fields. When we migrate CRM 4.0 to 2011 and 2013, that field comes as part of form it self. since that field is Business Required, we can not remove that field from the form. So when we create New opportunity manually, it throws error and we have to fill that field since it is Business required.

    Do you came across this situation?? I mean Is there any way we can remove that field from Opportunity Form, and let system decide what it want as part of that field??


    • Jonathan Lee Post author

      Hi Nick,
      In your migrations, when you migrate from CRM 2011 to CRM 2013, you will need to update all of your forms manually to use the new forms (Account, Contact, Opportunity, etc.) introduced in CRM 2013. Thus when you migrate over to the new “Opportunity” form, do not include the “Potential Customer” field in the new form. Thus for the Opportunity entity, you should not use the “Merge Forms” option and manually edit the Opportunity form; otherwise, “Potential Customer” field will be merged into the new form. Also, you should make a backup copy of the default 2013 entity solutions so that if you accidently include “Potential Customer” field, you can reimport the default solution to remove the “Potential Customer” field from your form.

      Now there’s one other unsupported option: manually edit the opportunity customizations.xml. Export the opportunity entity, open the customizations.xml, find the right “Potential Customer” field in the xml code and remove corresponding set of xml strings. However, this is not supported and you have to be very careful. Make sure you back up your solutions before attempting this so that if you make a mistake, you can recover.

      Hope this helps.

  • Nick

    Thanks for your quick assistance on this. Unfortunately we added that attribute accidently and can not remove it now. I tried to save as the form, but it always start from first active form, so it will bring CustomerId attribute/field by default and can not remove it.

    I tried other approach, that I open the Microsoft trial version and created new solution with only opportunity entity and exported as managed solution and imported back as managed solution in On-Premise test CRM and then save as that form as different name. Then deleted managed solution from test. That way I end up having the Opportunity Unmanaged Active Form with new CRM 2013/2015 style. Do you think this is supported way and will work ok?? is there any drawback that I may not aware of??

  • Jonathan Lee Post author

    Hi Nick,

    If you procured CRM 2013 Online trial, then an option you have is to create a solution with Opportunity entity only and import that unmanaged solution into your On-Premise organization. That will replace the existing on-premise form which contains “Potential Customer”; however, it will also remove any other fields you had added to the form which were not part of the default solution but you should be able to add them back into the form. Make sure the solution you create in the trial is the same version as the on-premise instance. If your on-premise is CRM 2013 with SP1 then your online solution export should be set to version 6.1.

    By the way, I noticed this approach no longer works in CRM 2015. So only other option was to edit the customization.xml and remove the strings associated with “Potential Customer” as I mentioned earlier.