Best Practices: Branching Logic for Custom End-of-Survey Messages vs. Workflow Scalability | Experience Community
Skip to main content
Question

Best Practices: Branching Logic for Custom End-of-Survey Messages vs. Workflow Scalability

  • January 7, 2026
  • 1 reply
  • 19 views
cami_mq
Level 2 ●●
Forum|alt.badge.img+4

Hi everyone, happy new year! 

I’m currently reviewing a survey architecture for a Relational NPS project and encountered a Survey Flow setup that raised some questions regarding scalability and best practices. I’d love to get your insights on this.

The Current Setup: The survey consists of a main block with about 22 questions. Following this block, there are multiple Branch Logic paths based on two variables:

  1. Device Type (Mobile vs. Desktop);

  2. NPS Group (Promoter, Passive, Detractor).

Inside each of these 6 possible combinations, an End of Survey (EOS) element was placed with a 'Custom' setting to show a specific thank-you message for each profile.

My Concerns: While this solution successfully delivers personalized messages, the flow feels redundant— especially regarding the device-type branching, which Qualtrics already captures natively. Moreover, it seems quite 'rigid' for future updates; for instance, if we decide to add a follow-up question for all respondents later, we would have to remove all those EOS elements first.

Questions for the community:

  1. Do you consider this the most efficient way to personalize the end-of-survey experience?

  2. Does anyone use Piped Text combined with Embedded Data or conditional Library Messages to simplify this and avoid multiple 'End of Survey' elements?

  3. Are there any technical risks (beyond manual maintenance) I should consider when keeping such a heavily branched structure?

I’m curious to see how you all handle highly personalized terminations without over-complicating the Survey Flow.

Thanks in advance for your help!

Cami

1 reply

arunxmarchitect
Level 2 ●●
Forum|alt.badge.img+3

​@cami_mq ,

You can make the 6-branch / 6-EOS approach work, but if you expect complex changes in the future then it is worth reviewing the options to streamline.

1) A cleaner pattern: keep one EOS and move personalization “upstream”

Instead of branching into multiple EOS elements, I typically recommend:

  1. Classify the respondent once (Promoter/Passive/Detractor) and store it in Embedded Data (e.g., NPS_Group).

    • Do this via Scoring, or a Branch that sets NPS_Group = Promoter/Passive/Detractor.

  2. (Optional) Capture device type into Embedded Data (e.g., DeviceType) using Qualtrics Meta Info (Qualtrics already knows this; you’re right that branching on it often feels redundant).

  3. Create a single “Closing” block right before the end that contains your thank-you content:

    • Option A (no JS, very maintainable): add 6 Descriptive Text items in that final block, each with Display Logic based on NPS_Group (+ DeviceType if you truly need it).
    • Option B (more dynamic): set an Embedded Data field like ThankYouMessage (or ThankYouMessageHTML) and pipe it into one Descriptive Text item.

  4. Put one End of Survey element after that closing block.

This preserves personalization but avoids the “EOS everywhere” problem-if you add a follow-up question later, you just add it before the closing block (no need to remove/relocate 6 terminations).

 

2) About “Library Messages” / conditional thank-you messages

Out-of-the-box, Qualtrics doesn’t really support conditional swapping of the built-in Thank You message in a clean, admin-friendly way (without workarounds). The most common workaround is exactly what’s described above: show the conditional content in a normal block, then use a single standard EOS.

3) When Supplemental Data Sources (SDS) is the “best” solution

If the thank-you copy is expected to change frequently and you want non-technical users to manage it centrally, an SDS can be a strong approach:

  • Key your SDS rows by something like NPS_Group + DeviceType
  • Pull in the appropriate message text (or an ID) and store it in Embedded Data
  • Pipe it into the single closing block

That way, you update messaging in the SDS, not in Survey Flow.

Support page: https://www.qualtrics.com/support/survey-platform/survey-module/sds/supplemental-data-sources-basic-overview/

 

Thanks,

Arun

https://www.linkedin.com/in/arun-raj-023b7836/

Terms & ConditionsAccessibility statement