1 Reply Latest reply on Nov 7, 2018 6:56 PM by HongTai

    Linkage of  contact to account based on company ID


      Hi there, I did a quick search on the question below and didn't see anything similar.  Please reach out if you have some ideas. 

      We are looking to do more targeting at the account level and company level.  Currently our firmographic data is at the contact level but we would like to begin leveraging the account table.  The constraint we have right now is that the firmographic information is completely dependent on the particular contact having that particular data point.  We thought about continuing that this but with all the additional company level data it would just over complicate our contact washing machine and make it very difficult to maintain.  We had been reluctant to link on SFDC Account ID as most of our Eloqua contacts are not contacts in Salesforce. Bullets below reflect where I am thinking but not sure if there is some sort of eloquirk that would be a constraint.


      • Account record will contain uploaded firmographic data as well as SFDC account data
      • Linkage between accounts and contacts will be the Eloqua Company ID field that will be written to the contact record.
      • Linkage between accounts and SFDC will remain the SFDC Account ID on the account record
      • Create look up tables for domain to Eloqua Company ID and SFDC Account ID to Eloqua Company ID.
      • Activate update rule that uses  the two tables but gives priority to the salesforce account ID
      • A contact can have their Eloqua account ID changed if the SFDC AccountID is updated.
      • When updating records in the account table use Company ID as the key


      Would welcome hearing from anyone who is doing anything close to this or has additional thoughts.



        • 1. Re: Linkage of  contact to account based on company ID

          Hello MD!


          Would you be able to let me know what are the timing tolerances you currently have for processes / segments that run on this linkage?  Reason I'm asking is because I'm envisioning the flow below:


          1. New Contact / Lead gets created where a background filter / feeder determines whether or not the contact is linked to an account.  If it's linked to an account, drop out.
          2. If NOT linked to an account, we wait for approximately a day (or other specified time interval) and check again if it's linked to an account or not.  IF NOT, proceed to next step.
          3. After the wait AND SFDC AccountID field continues to be blank, we pass the contact into a update rule that initially takes their company name (eg. COMP1) and puts in a "ELQ Company ID" field as COMP1ELQID
          4. Pass the contact into a form submit app that uses the COMP1ELQID to update an account record, with only the ELQ Company ID field to the Account Level SFDC AccountID fields mapped - that way if a ELQCompany ID record exists, we don't create a new one but we do create a new one if it doesn't exist (this brings up the issue of which Company Name should be applied, but we can go into that later)
          5. Afterwards we pass the contact into an update rule again that moves the value in ELQ Company ID on the contact level into SFDC Account ID - this should "rig" a contact update to get the contact mapped on the "temporary" ID.

            **Caveat to this is that we'd need every contact to type in their company name in an almost exact manner - but I'm focusing on the framework of this for now and other means can be used to standardize this possibly.

          6. When the time does come when a contact gets created in SFDC, an account record should exist and get pulled in by the Get Accounts Autosynch and create a new account record in ELQ.  The Get Contacts Autosynch should bring over the actual SFDC Account ID - which after the most recent contact update should link it to the new account record with the actual SFDC Account ID.
          7. As a new Account Record is created via a synch, we'd need to likely pass such new records into a program builder asset that runs a dedupe rule to delete the account record that held the "fake" company ID


          Things to absolutely look for at this point is to ensure this won't cause any issues with your integration program, as we are forcing a fake value in out of necessity as we only have one account linkage mechanic (as easy as a filter that excludes any Account IDs that end with ELQID).  At the same time, I haven't dug into the rabbit hole on the mappings / Account creation mechanics you have in SFDC when a lead gets converted into a contact.


          It would really help if you can  give me a bit more insight on the data flow you've set up in SFDC in terms of the lead conversion process plus how you're using accounts for segmenting.  After that, I can see if timing can be an issue or not + whether or not some integration assets need to be updated.  If by any chance some of these details are sensitive, I would be more than happy to look at email screenshots too (you can reach me at hongtai@gospecmarketing.com).


          Looking forward to hearing back!


          Best Regards,

          Hong Tai Lee