We've released Groups, a new feature that enables us to connect community members of similar industries and interests in a shared, private space. You can check out all of the details here, including information about who can join, how to join, and what Groups are currently offered. Please leave your feedback through this Community Groups Feedback Survey.
Survey responses mapped to wrong O Data in Q & in SFDC (Salesforce - Q Integration)
I'm having problems with the SFDC integration with Q.
Here is our implementation structure: Case & contact data from SFDC --> Contact Directory in Q --> Survey trigger --> Survey absorbs all case & contact info as embedded data. We have 3 different channels from SFDC to Q to trigger surveys and collect customer feedback on 3 of our different support groups (that serve the same customer base)
Recently, I have seen multiple instances with duplicate survey responses registered for the same case. After my initial analyses I found that customer took 2 different surveys (with diff case #s that I can infer from the distribution data) but the responses are mapped back to one case #. After talking to Q Support, I understand that when a new case (lets call it C2) for a customer (let's say "John") is closed in SFDC and info sent to Q to trigger a survey, Q UPDATES all data fields associated with the customer A, be it contact data or case data. Now what happens if the customer takes the survey which was sent to him for the previous case (C1?); his responses are captured by the tool but they are incorrectly mapped with "C2" case info.
Q says that it is a unique issue that we face in our Org but I can't believe this isn't a common problem. anybody came across this issue and/or can suggest a solution?
Note: I know the option of turning off contact de-duplication may help (which is what Q suggested) --> I understand this may help by maintaining duplicate contact records in the Contact directory with all case info (But to me, this isn't the best solution or approach as this kills the purpose of Contact Directory)
What would be more ideal in my opinion is Q to have a "Operational data directory" that links with the "Contact Directory" on a many:1 relationship. But I don't get the feel that Q has the data strcutured this way.