locked
CRM 4.0 Contact Entity - Primary Key RRS feed

  • Question

  •  

    Hi,

     

    I am customizing the contacts entity within CRM 4.0. I would like to change the primary key from the fullname to a unique identifier of my own choice. I cannot change fullname or alter the way it is generated, I want to import my own primary attribute.

     

    We have a intranet system running alongside CRM and it has its own GUID's which we would like to use. The main problem is that when we want to import onto a custom link entity, the import fails if we have 2 contacts with the same name as you have to import onto the fullname field!  We could like to import onto a a different field and still sustain the link.

     

    The initial idea was to append the guid to the contact and use the fullname field as a form of GUID field. The problem is that this is generated by the use of the first and last name!.

     

    We are going to do the above to the accounts entity, the problem is that the first & lastname are concatenated.

     

    How do we get around this?

    Monday, October 27, 2008 2:36 PM

Answers

  •  

    We intend on allowing users to import data onto linking entities at their own will. This includes some custom entities linking to the contact entity. Obviously the users are not going to know the CRM GUID for a contact, even our intranet system wont. Is it advisable to maintain the CRM GUID and our intranet GUID in both systems then?
    Tuesday, October 28, 2008 10:19 AM

All replies

  • Hey Martin,

    You can't change the primary key of an entity, it is always the GUID associated with the entity. This goes for all objects within MSCRM. If you want to import your own primary attribute, I suggest creating an 'integration key' custom field and prior to creating the record in MSCRM, check this field value to see if any exist. If so, update, not create.

    >>
    We have a intranet system running alongside CRM and it has its own GUID's which we would like to use. The main problem is that when we want to import onto a custom link entity, the import fails if we have 2 contacts with the same name as you have to import onto the fullname field!  We could like to import onto a a different field and still sustain the link.
    >>

    I would use the custom field suggested above to specify as your import field. Essentially you will have two uniqueidentifiers in MSCRM, one for MSCRM and the other your integrated system.

    As a side note, it is possible to specify the GUID you wish to use when creating an object in MSCRM through the SDK, not possible to update, but possible to create. I would still go with dual GUID's however.

    Cheers,

    Karlo

    Monday, October 27, 2008 5:22 PM
  •  

    We intend on allowing users to import data onto linking entities at their own will. This includes some custom entities linking to the contact entity. Obviously the users are not going to know the CRM GUID for a contact, even our intranet system wont. Is it advisable to maintain the CRM GUID and our intranet GUID in both systems then?
    Tuesday, October 28, 2008 10:19 AM
  • Hi Martin,

    It depends entirely on what you would declare as your 'linking' key. If users manually update information, you may want to present them with a form for looking up a contact/account in MSCRM and then updating the information manually. If you are creating your contact record in MSCRM initially then it would be a good idea to pass this GUID to your other system, creating the record in that system and updating your '2nd system GUID' with the newly created value in your 2nd system. Similarly if created in the 2nd system, pass that GUID across to MSCRM and update the 2nd system with the newly created GUID of the MSCRM record.

    This is usually the safest option as you can easily determine which records in both MSCRM as well as system 2 have or have not integrated. Similarly performing a lookup will be absolute as the MSCRM Guid is unique.

    Hope it helped.

    Karlo



    Tuesday, October 28, 2008 12:28 PM