@Mitchell Sokol Interesting topic… I would actually see this kind of queuing on sender side to achieve some synchronous processing. But I get that this does not solve your issue.
When I think about it, I always end up at a dead end. For example, I have considered whether it would be possible to block an entry until processing is complete, for example by setting a flag on the entry. However, if two requests are processed asynchronously, checking the flag doesn't help much…
Creating one entry in the imported data project for each message (all having the same ID for the same chat to group them) with exact timestamps (millisecond level) will also not be possible in your setup I guess? This would avoid overwriting, based on the chat ID you could group and based on the timestamps you could sort. However, you would lose the concatenated chat protocol.
Let me sleep a night over it.
@Mitchell Sokol Interesting topic… I would actually see this kind of queuing on sender side to achieve some synchronous processing. But I get that this does not solve your issue.
When I think about it, I always end up at a dead end. For example, I have considered whether it would be possible to block an entry until processing is complete, for example by setting a flag on the entry. However, if two requests are processed asynchronously, checking the flag doesn't help much…
Creating one entry in the imported data project for each message (all having the same ID for the same chat to group them) with exact timestamps (millisecond level) will also not be possible in your setup I guess? This would avoid overwriting, based on the chat ID you could group and based on the timestamps you could sort. However, you would lose the concatenated chat protocol.
Let me sleep a night over it.
Thanks for thinking about this. I may end up creating my own API to manage updating the Qualtrics IDP. Probably I can implement some locking mechanism in my .NET API.