Authenticating against a contact list - registration survey

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

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! 😎

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.

Maybe this image will help:

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! 😋

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

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

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. 🧠🏆️

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.

Well, it works, but not consistently. Here's what I have:
.......
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.

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?

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.

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

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?

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: