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:
- 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.
- 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.
- 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
- 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)
- 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.
- 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.
- 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 firstname.lastname@example.org).
Looking forward to hearing back!
Hong Tai Lee