Authenticating against a contact list - registration survey | XM Community
Solved

Authenticating against a contact list - registration survey

  • 19 December 2017
  • 22 replies
  • 671 views

Userlevel 5
Badge +10
So, I'm setting up a survey to use for registration that will have functionality to add them to a contact list when they register and then, if they've already registered, it will branch and say, "Thanks for playing" (or something like that 😉 )

I've set up a Contact List Trigger, but am struggling with getting my Authenticator to work. Here's what my survey flow looks like:
!

In going through my previews to test, after I've responded that I will attend and use the same email (over and over), when I submit, I get a login screen to enter my email address.

Here's my CL Trigger:
!

I feel like I'm so close...it's frustrating. I also feel like this should be basic stuff, but, gah!!!

Help, geniuses!! 🙂
icon

Best answer by rettweber 19 December 2017, 23:41

View original

22 replies

Userlevel 2
Badge +3
Can you try to have settings in authenticator options as below:

Max authentication should be 1 instead of 3 as default.


!
Userlevel 5
Badge +10
@NK_Tripathi I changed it, but it's still requiring me to login, when I just want it to check and see if I've already responded. If I have, I want it to kick me to the end of my survey.

Basically, I want it to cross-reference the contact list.
Userlevel 2
Badge +3
Can you please make sure to select the check box as - Allow authenticating respondents to retake authenticated section.

This should work just fine. If not I can send a example qsf.
Userlevel 2
Badge +3
And Yes, make sure you'are passing Email in query string, so it gets the value and authenticate.

Your authenticator need to be at the top. I see block has 10 questions above authenticator.

You would need to have your authenticator at top before they enter in survey.
Userlevel 5
Badge +10
@NK_Tripathi I don't want them to have to login/authenticate to complete the survey though. The trigger is creating the contact list on the fly and then if they go back to the survey at some point in the future and try to redo it, I don't want them to be able to. I want them to get the custom end of survey message that tells them they've already registered.

The issue we run into is that we have a lot of people do duplicate registrations and we'd prefer to just tell them, "Thanks but we already have you on the list." Does that make sense? Sorry this is confusing.
Userlevel 3
Badge +6
Hi @MichellC,
have 2 authenticators, one to authenticate using sso and the other to authenticate against your contact list (under and within the SSO authenticator).
process:

set a contact list trigger to add individuals using data from the SSO authenticator below

SSO authenticator (Single Sign on)
1. do NOT associate respondent with panel
2. save the username associated with your contact list from capture respondent identifying info

Contact authenticator
1. set to your contact list
1. set to your contact list
2. allow select prefil for your authentication fields and use the embedded data from SSO to prefill
3. set option to only allow 1 attempt (this will make the authenticator act as an if/then block)

put your survey blocks under the second authenticator.

use an end of survey element under the first authenticator but not under the contact list authenticator to send the person back into the same survey, They will be added to the contact list, because of single sign on, they will not be asked to sign in again, they will be sent to the survey.

See the image below. I sued this for something else and whited out the sensitive bits. Put your questions where the embedded data and if then statement is. I added a note to let people know they were not in the contact list. You would not want that. instead you would just have the end of survey element sending them back into the same survey, but because they would have been added to the contact list, they would now go through the survey.

I have some documentation I developed for using end of survey elements, piped text, and authenticators. There is a lot you can do with these.
Hope this helps. I wrote this up pretty fast.

Rett

!
Badge +1

MichelleC: Did you ever get an answer to your question? I'm having the same trouble, tryng to do the same thing.

Badge +1


Userlevel 5
Badge +10

dduross wow, this was a while ago. I was helping a unit with the survey and I'm not even sure which one it was at this point. Did you try rettweber Accepted Answer? Did it not work? Where do you feel the glitch is happening? We'll figure it out together! 😎

Badge +1

I'm so glad to hear back from you. I figured since your post was 3 years ago, my question was essentially a message in a bottle.
I have everything in my survey set up as in rettweber's post--with 2 exceptions:

  1. I don't have the 3 end-of-survey blocks added (something I didn't think to do, since the configuration in the flow has never taken me to any of the branched blocks in the survey).

  2. My branch logic condition is--if TRUE (responder is IN the contact list), show the "you've already registered" block, if FALSE (responder is NOT IN the contact list), show the "registration info" block.

I have my contact list trigger action set so that it will add the contact only IF the "registration info" block is displayed.
I feel like I'm being a dope. What am I doing wrong?
Thanks for any help you're able to provide.

Badge +1

Maybe this image will help:
Capture.PNG

Userlevel 5
Badge +10

dduross , give me a few days and I'll see if I can dig into this. We're getting ready to have classes start (I work at a University) so things are crazy busy right now! 😋

Badge +1

I understand. This is week 2 for us at the University of Kentucky.

Userlevel 3
Badge +6

Hi dduross ,
MichelleC is at my institution. I may have helped solve her problem offline. Should have posted info here. So a little about debugging and a potential issue in your flow.
1) I suspect that email is not the name of the field passed via shiboleth. Your IT should have the specific string of letters and numbers that pulls that information. See debugging info below.
Debugging survey flow.
You need to make sure that individuals are going down the path you expect. This requires a little old school debugging.
1) Use Embedded data to help you figure out what is happening.
a. add embedded data in the survey flow. add embedded data blocks in the survey flow to add data so you can figure out what logic has been triggered. I often have different events occur based upon conditions (kick out of survey because don't authenticate, authenticate one way but not another, pass to another survey). I use an embedded data field to indicate the outcome. This proves useful if someone emails and asks questions about what happened to them. It is also useful if you have an embedded field that contains the outcomes with text such as 'authenticated as student passed to survey ...' Then look at the survey of a person and you can know what happened to them.
B. In the first authenticator you are trying to get the email and put it into the embedded field email. I would call the field something other than email, as that may accidentally overwrite another email variable. You could call it auth_email which is not used. Think about what are likely to be embedded data field names and be sure not to overwrite them. There is a list in the Qualtrics Help pages with some of those words.
2) Use Piped text to see embedded data. Check to see if the data actually shows up. Create a block with a question that includes the data you are trying to capture and use as piped text. You can call the block testblock. Place the block at different positions in the survey flow to check on the status of variable while you are taking the survey. When you are done, don't forget to remove the block from the survey flow.
I sometimes add an if/then block that says that if I authenticate in, show the test question. I can change the name to someone else if I need to test using student staff.
3) use end of survey block. These blocks help make sure that recipients explicitly end the survey where you want them to. It also makes sure that you don't overwrite your own embedded data fields as described below.
4) what do you need to check?
a. Is the Shiboleth authentication passing you an email and actually authenticating? Maybe you don't get past that first authenticator (put an embedded data block immediately after the first authenticator (status = Shib Authenticated )and outside the first authenticator (in case you don't authenticate; status = not Shib Authenticated). You could also put the test block here right after the first authenticator to see if email was passed from the authenticator.
b. The second authenticator is not working. Same sort of thing. Put another embedded data block immediately under the second authenticator (status = Shib Authenticated, on contact list). with a second embedded data field inside the shib authenticator but outside the contact list authenticator (status = Shib Authenticated, not on contact list).
Using end of survey blocks can be helpful in making sure a person ends the survey when you expect it should be ended and you do not overwrite your own status embedded fields.
c. you also need to make sure that you pull in the data from the contact list. If someone not on the contact list has not been registered, then just use the second authentication block as an if then block. The second to last add new element here in your image above would be where individuals that are not in the contact list should end up.
I hope this helps.
Rett

Userlevel 5
Badge +10

dduross as is the usual, rettweber is a genius with this kind of stuff. There have a been a ton of times that I've called on him when I was having issues with my surveys and his advice and experience within the Qualtrics platform was unparallelled! And although he's too modest to toot his own horn, he's a PhD data scientist and is an expert coder. 🧠🏆

Badge +1

Thanks rettweber and MichelleC for your generous responses.
When I delete my second authenticator, my first authenticator works as it should. It captures the only response identifier that (as far as I know) is available to me (Email) which is fine.
I can move on and fill in the contact fields and complete this preliminary registration survey.
My contact list trigger successfully adds me to the contact list.
Now I need a little time to screw around with the second authenticator as you describe above.
I'll let you know. Thanks again.

Badge +1

Well, it works, but not consistently. Here's what I have:
Untitled-1.png.......
The first time through (in RED above):
A: Descriptive text field in "SSO_Email" block shows me I've passed the first authenticator.
B: I get dropped down to the registration block, make my entries, and complete the survey.
My contact list trigger adds me to the contact list, and creates an embedded field "registered," and sets the value to "yes."
.......
The second time through (in GREEN above):
A: same
B: Descriptive text field in "registered" block shows me I've passed the second authenticator (it's pulling from the contact list).
C: I go straight to the end of survey.
.......
THE PROBLEM is that the third time (and every time after) it takes me down the RED path again, as if it doesn't recognize that I'm in the contact list. I don't understand why it doesn't just continue to send me down the GREEN path? Nothing has changed.

Userlevel 3
Badge +6

Hi dduross,
OK, just so you know, you can put actual text in for the embedded data. Overwrite the text that says value will be set by panel or URL.You can also pull data from the panel. It was not clear if you knew that.
If you check to see if checking off allow authenticating respondents to retake authenticated section produces the result you want(in options on second authenticator). I don't think so, but it is quick and easy to check, so thought I would suggest it.
Do you want a new survey every time they take the survey?
image.png

Badge +1

rettweber,
The options for my second authenticator look like what you have above, except that I've set the retries to 1.
This PREsurvey is just a way to get some personal info about the responder that will go into a contact list. Once they've completed this PREsurvey they're taken directly to the actual SURVEY.
The SURVEY is something they can take as many times as they need to, and because they're in the contact list they don't need to re-enter their personal info.
The way they get to the SURVEY is always through the PREsurvey, which they're immediately redirected to if they pass the second authenticator above.
SO it works if you've never taken the SURVEY before, and if you come back to take a second SURVEY. But every time after that, the PREsurvey acts as if the respondent is NOT in the contact list.

Userlevel 3
Badge +6

dduross Would you be willing to collaborate on the survey with me? I am afraid I can't work out what is happening without that. It looks like a test survey anyway. I won't be able to see the contact list, but I should be able to see just about everything else.
Note that I won't be able to work on this until after work today.
Rett

Badge +1

rettweber, absolutely, yes thanks. It IS just a test survey, and there's nobody in the contact list but me. Although I'm not sure how to do that?

Badge +1

Thanks rettweber for your help with this, and MichelleC for pointing me in the direction of your colleague.
The solution was actually very straight-forward. In the flow below, the key change was in the options for the second authenticator, which needed to allow respondents to retake the authenticated section.
Here's the flow:
Untitled-2.png

Leave a Reply