Candidate experience guidance needed on achieving survey send logic

Question

Am interested to find out some clever ways to go about achieving the conditions for a candidate survey to be sent. Hopefully someone on here has done something very similar or identical. 😅Survey to be sent to:for each application, anyone who has been in both Phone screen and Decline later buckets	for each application, anyone who has been in both Phone screen and Offer accepted bucketsCurrently, I have a report set up that tells me the date/time a candidate entered entered a bucket and has a row for each bucket. This report is cumulative so the number of rows only ever grows.i.e. if Bob enters phone screen on 26/10/2025, the report that runs at 10pm on 26/10/2025 will have 1 row. Then if Bob enters decline later on 28/10/2025, the report that runs at 10pm 28/10/2025 will have 2 rows (Bob in phone screen and Bob in decline later).The report above can also be modified to be non-cumulative which means that in the same example, Bob will have 1 row in both the 26/10/2025 and 28/10/2025 reports.There are a couple of problems I’m facing in my mind:If I use the cumulative report, how would I get the logic to recognise that a survey only  needs to be sent once for each application instance (i.e. if Bob applies for 2 different jobs days/weeks/months apart, he will get 2 surveys)?	If I use the non-cumulative report, how would I get the logic to recognise that Bob has been in both the Phone screen and Decline later (or Offer accepted) buckets?

Lpena · Answer

Hello, BenchBased on the requirements for sending a candidate survey to a hiring manager, the desired logic for distribution is complex and depends heavily on how the distribution data is processed.The Two Conflicting ScenariosYou have two main scenarios regarding how hiring managers receive surveys:Scenario 1: Multiple Surveys PossibleA hiring manager receives multiple surveys when they handle different applications, even from the same recruiter. This is possible because each different application triggers a separate transaction.Scenario 2: Single Survey EnforcedA hiring manager receives only one survey when multiple applications progress similarly with the same recruiter. This requires grouping transactions to ensure the manager isn't sent too many identical surveys.How Current Distribution Methods Handle ThisThe two primary distribution methods conflict in their ability to meet both scenarios simultaneously:Real-Time / Single Transaction DistributionThis method supports Scenario 1 (multiple surveys possible) because each transaction is processed individually.It does not support Scenario 2.Batch File ImportsThis method supports Scenario 2 (one survey per recipient) because it groups multiple transactions for a single recipient, resulting in only one survey distributed per batch.It does not support Scenario 1.Conflict: Because the requirements conflict with the data provisioning methods, a straightforward solution that satisfies both conditions simultaneously does not exist. Real-time scheduling allows for scenario 1 but not 2, while batch import supports scenario 2 but not 1.Conclusion and Next StepsA direct solution that satisfies both conditions simultaneously (allowing for multiple surveys in some cases, but enforcing only one in others) is not possible with the current standard distribution methods.Clients typically need to:Decide which scenario (Scenario 1 or Scenario 2) is more critical for their operational needs.Adjust their data feeds and distribution scheduling (real-time vs. batch) to align with that chosen scenario.If you are still having issues determining the best approach or need to explore highly customized workarounds for your specific data feed, we suggest you submit a ticket.through your Customer Success Hub.➡️ https://support-portal.qualtrics.com/

Sign up

Login to the Community

Scanning file for viruses.

This file cannot be downloaded