1

We are using Salesforce with our Drupal site for Registrations and Orders. When someone submits their registrations, we us a SOQL query to lookup Contacts with matching First Name, Last Name, and Email. If we find one we update fields if needed and save the returned ID and if we didn't we create a new one and store the new ID.

This works excellent 98% of the time but we are noticing some duplicate Contacts being created at the same time. A duplicate is only created if they were brand new records. What we think is happening is people can register for more than one event at a time and are presented with multiple registration forms for each event. The query runs for the first one and creates/updates and then runs again for the next one and so on.

Doing some research it seems that newly created records are not always immediately available to be queried again because it needs to be indexed. So after the first Contact is created, the next time we query First Name, Last Name, and Email we return no results if the other record hasn't been indexed yet.

One thought to perhaps remedy this is to store the newly created Contact into a db table with its ID, First Name, Last Name, and Email and before we run our normal query against Salesforce, we query our db table to see if it exists and grab the ID and only use the ID in the SOQL query to find a match.

But this will only solve the problem if the Salesforce ID is immediately and always available for SOQL queries and isn't subject to indexing and just the more detailed record information like names and emails are.

Does anyone know if this is true? Can you immediately query IDs in Salesforce without worrying about indexing issues? This is difficult to test at the moment since it's so sporadic.

2
  • I am not sure about delay caused due to indexing part. But in your scenario wouldn't preventing of duplicate records help? You could setting a duplicate rules with a matching rule on first name, last name and email. This will ensure that duplicate records are not created. In your contact insertion code, you could put the insert statement inside a try catch statement and identify the exception thrown as due to duplicate error. Then proceed accordingly with the knowledge that the contact is duplicate. What do you say?
    – Prajith
    Commented May 4, 2016 at 20:32
  • Do Rules in Salesforce trigger immediately against API calls? I know with Flows we have had to include a slight delay before they run because they do not respond fast enough when we push data up through the API. But if they do, that is an interesting idea to create a duplicate rule ahead of time in SF. Commented May 5, 2016 at 13:30

2 Answers 2

1

Interesting question! It sounds like the short timeframes causing this issue are related to the specific scenario of a person submitting multiple registrations back to back.

My (wild) guess is the bottleneck is due to time delays between API callouts- presumably you wouldn't have this problem if these SOQL / DML statements were being made by apex code within SF.

Two Three thoughts:

  1. Have you tried creating an External ID field that you can query instead? This might improve indexing speed. E.G, if you were to concatenate the contact first name, last name, and email into a single text 'ID', you could set that as a unique external ID and query that directly.

  2. Have you tried using the SaveResult() class when first inserting to get confirmation that the DML operation was actually completed by the time you attempted to query again? In other words, how sure are you that the record was actually created and just not indexed?

  3. Regarding your specific scenario: Your short timeframes are due to creating/querying the contact for each individual registration, when multiple regs are being done back to back. This doesn't answer your question, but as a possible solution what if you were to only attempt to create/query a single contact only after all the registrations were completed in that sitting?

3
  • Excellent ideas: 1) Does having an External ID to query later really better than just using the Salesforce ID provided after we initially created the record? 2) I didn't know about that class actually, but I get a returned ID each time a record is created through the API and I am storing that in a table now which I can query against right away before I query SF. Does SF create records temporarily at first? 3) They fill in each registration on the page and then submit, this fires off a Drupal hook for each registration being saved which I utilize my api call in, so they are separated out. Commented May 5, 2016 at 13:34
  • No, an external ID wouldn't be better than the record ID for indexing - it would just be better than querying using fields like Name and Email in the 'WHERE' clause. So you're saying you are querying using the IDs you get from insertion, and still not getting the result? I'm stumped.
    – smohyee
    Commented May 5, 2016 at 23:49
  • At the moment each query stays the same by using the names and email but my solution is to use a previously stored Salesforce ID from recently created contacts to query against first to see if it is found. I can do it no problem but not sure if that will solve the problem as its not easy to really test this. Sometimes records seem to be immediately available for query and other times their not, based on names and emails not id. Commented May 6, 2016 at 0:55
1

Just to answer this for future reference it does indeed work if you use the Salesforce Record ID for any immediately following queries that take place before the record is properly indexed up in Salesforce.

So in my case, I set it up to first look in my database table for matching rows with First Name, Last Name, Email and if it found a match it would use the ID in the query against Salesforce.

If it didn't find a match, it would query as normal (for instance in case it was an existing Contact in Salesforce or if something went wrong writing to the database on the last new Contact creation.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .