Introducing the XM Directory Task
+4Last week, we introduced a new feature, the XM Directory Task. This feature is replacing an existing one called the Distribute Survey Task.
!
Correct me if I'm wrong, but it's still not possible to distribute a survey to a particular transaction?
The risk with the way XMD and ED currently works is that attributes on a contact in XMD can change after a survey has been distributed, but before the respondent actually clicks the survey link. This is especially important for high-volume call center transactional CX programs, where attributes on contacts in XMD can be overwritten many times throughout one day, but contact frequency settings prevent multiple surveys from being distributed.
+23@Pavel We are facing exactly same issue. Due to this issue, we cannot even deduplicate our Directory. So frustrating
+67Thanks, @KatharineS -- just to be clear, the use case for this feature is to distribute surveys via an e-mail contact list, not for repeated distribution through a site intercept using a cookie, correct?
+4@AdamK12 Correct, this is an email or SMS contact list distribution, not site intercept. No cookies are involved.
@Pavel & @MsIreen The XM Directory task can be used to add transactional data to a contact. Even if you choose to distribute a survey, you can add a contact and update transactional data. (Apologies if I'm misunderstanding the question!)
> @KatharineS said:
> @Pavel & @MsIreen The XM Directory task can be used to add transactional data to a contact. Even if you choose to distribute a survey, you can add a contact and update transactional data. (Apologies if I'm misunderstanding the question!)
Yes, you misunderstand. A survey is distributed to a contact as a whole, not the transaction that was added with the XMD task.
Between when the survey is distributed and when the respondent clicks on the survey link, the contact's attributes can be overwritten with new data many times, and survey flow will always set ED from contact at the time the link is clicked, by which time the original data which triggered a distribution and contact creation is already outdated.
The only solution would be to be able to distribute a survey to a transaction, and/or set ED from a particular transaction, rather than the contact.
The current implementation makes Transaction functionality in the XMD task effectively useless, since it just highlights what is essentially a giant feature gap which can only be solved by some creative use of Automations in XMD. There is, as far as I know, no way to deal with this through either API or Actions.
+4Hi @Pavel - sorry for the confusion here! To make sure I can address your concerns, I spoke directly to the product team involved.
Do you see here, in step 9, where you can choose whether to "Save and update embedded data" or "Add as a transaction to the contact info?" When you choose "transaction," this ensures that the contact's attributes are not overwritten, but saved as distinct transactions connected to that contact. This option is available when you use the XM Directory task to update a contact or to distribute a survey. This means you can effectively distribute to the transaction just created, or update a contact with a new transaction without overwriting previous data.
However, this "transaction" option is only available to customers who have access to XM Directory (not just the XM Directory Task) and who have permission to use the directory. If this option does not appear while setting up an XM Directory task, it is worth reaching out to your Brand Administrator to see if this is an account permissions issue or due to the Qualtrics license you have.
OK, so consider the following scenario:
1. John calls Qualtrics at 12:00 and Speaks with Jane in Sales.
2. An XMD task is triggered through a JSON event which adds the call's metadata (including Jane's name) to John's contact in XMD as a transaction, and a survey is distributed.
3. John calls Qualtrics again at 13:00, and speaks with Susan in Support.
4. Another XMD task is triggered through a JSON event which adds the 2nd call's metadata to John's contact in XMD as a transaction, but no new survey is distributed due to contact frequency settings.
5. John finally clicks on the survey link at 13:15, and completes the survey.
If call metadata is set in the ED block in the Survey Flow, which transaction data will end up in the response as embedded data - the 1st call with Jane or the 2nd call with Susan?
Unless Survey Flow and XMD functionality has fundamentally changed recently, it will be Susan's data, even through the survey was originally distributed for a call with Jane.
+23I would like to add my 5 cents also on how unclear the transactional metadata is.
We have a support survey integrated to Salesforce, a survey is sent when a case on SF is closed. if respondent gives low scores, a child case is created automatically. It is to be attached to the original case to follow up on what went wrong there. If there are multiple cases closed for the same person, the case SF ID on the contact in XMD gets overwritten every time.
So, for example, we have same customer, their case A closed on Monday, Case B closed on Tuesday, Case C closed on Wednesday. We send them a survey invite on Monday with email text asking about case A.
Meanwhile, the value of the Embedded data field "Case SF ID"on the Contact will be "Case A ID" on Monday, then it will change to "Case B ID" on Tuesday and on Wednesday the value will become "Case C ID".
On Wednesday evening this particular person decides to give their feedback. They think they are giving feedback for Case A which went really bad, so they give really poor scores. The system creates a child case in our SFDC, parent case to this one will be Case C (as the values have been overwritten). I am not mentioning now all other case attributes that are overwritten in the above scenario.
I honestly do not see how the transactional fields are solving this issue.
Correct me if I am wrong here
+4> @KatharineS said:
> @Pavel @MsIreen I apologize for the confusion here - sounds like you have some pretty specific setups in this case. I’d recommend getting in touch with our support team here so they can better dig into your specific case with you.
I've had several discussions about our use case with EPS, and the conclusion was that there is no solution. There is a complex workaround involving Automations, but it's not really relevant for us since we have hundreds of thousands of distributions every month via API.
While not quite the same, I think @MsIreen and I have somewhat similar use cases, and I wouldn't go as far as calling them "pretty specific", because any large-volume transactional contact/call center CX programme will face the same issues.
The simple truth is, Research Core and XMD were just not designed to handle the demands of large enterprises. That's why I initially started to question the new transactions functionality in the XM Directory task - I just can't see its practical utility, and what problem it's supposed to solve. Transactions as a feature, as it's implemented in Qualtrics now, is next to useless, and a lot of work would be required to actually make it work as an enterprise-oriented feature.
Hi Pavel
Just wanted follow up after the comment from MsIreen to let you know that I was concerned in what you were saying regarding transaction data when using an Action with a 'Distribute Survey Task' to send out a survey (plus adds the contact to a contact list). Your reply read as if transaction data was not working as expected meaning that if one person received two surveys before acting on the first one then their metadata would be overwritten with the most recent data.
After testing this scenario, I can confirm that the transaction mode, is working as expected and the metadata remains separate. In the Directory List, I click on my test name in the List and can see both surveys sent with separate transactions / metadata and after completing the survey, I have had a look in the survey's Data & Analysis tab and can see that the metadata has come through as expected and each response has maintained it's separate data.
In my action task I use these options, the most important setting being to select 'add it as a new transaction to your XM directory contacts':
2 x different transactions with unique metadata and response data (when you expand it) is the result:
Apologies if I've misunderstood what you are trying to highlight as the issue you are seeing. If you could explain a little more I'll try and do some more tests. FYI, I have XM Directory / CX. These two surveys were sent out within about 10 minutes of each other on the same day using this Action/Task.
Thanks
Rod Pestell
Rod_Pestell actually this was solved a while back. Not quite sure when, but I've had a number of JSON event-based actions setup with XMD tasks which add transactions, totalling a few thousand distributions per day, and it's been working flawlessly.
Well, the transaction part has been working flawlessly, but JSON events themselves are still a pain to work with, and I hate having to create 2 separate XMD tasks in each action only to be able to update both transactional data and attributes.
Hi Pavel ,
Good to know - I was wondering if it had been solved as the last reply was back in March last year. Talking of JSON, I managed to do my first JSON Webservice task the other week, amending multiple embedded fields in a survey response. Wish it could amend actual response data like API could (but that I'm told is a very complex thing to do!) My challenge is to now manipulate a data field using a javascript code task and then use that in an embedded field through JSON through a webservice task - essentially I want to make the timestamp more friendly (From this: 2021-04-01T07:59:52.472Z to this: 2021-04-01 07:59). If you have any pointers, I'd be very grateful.
I should start a new thread for this really!!!
Thanks
Rod Pestell
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.