Hello @gingersauz!

What I’ve done in that scenario is that I define a metadata field that identifies if the person is (or is not) in the directory. That way you could make a branch in the survey flow like this:

If it’s in the active directory (let’s say AD=1) → use the SSO 

If it’s not in the active directory (let’s say AD=0) → don’t use the SSO. In this scenario, you have to send the invitation via email or get the personal links. 

In any case, you will declare all metadata as embedded data in the survey flow. 

Let me know how it goes!

Ok that makes sense.  I wasn’t sure if I could use both types of link in the same survey.

So my branches will basically be the full survey in each branch, with the authenticator at the top of one, but not the other.  Yes?

As for the embedded metadata, if everyone, even the ones not in active directory, are loaded as participants in the survey what metadata do I need to embed?

I made some tests and actually it would be enough with a configuration like this: 

If you upload the new field (let’s say AD) and put 1 for those who are in the active directory, you could use that condition “if metadata AD Not equal to 1” then use the authenticator. That way, you’ll have 3 scenarios:

1. Personal link with AD = 1: it will skip the authenticator (and as it took the AD, it will take all other metadata).
2. Personal link with AD = 0: it will ask for authentication and take all metadata from there. 
3. Anonymous link: it will ask for the authentication and take all metadata from there.

You don’t have to nest the survey blocks inside the authenticator. In this case, the authenticator just brings the info for them who are not in the active directory.

Ah, that is much cleaner!  

We have an existing field we can use called Worker Type with values of Regular & Contract. 

REALLY appreciate you taking the time to assist me with this, especially the scenario testing!

muchas gracias!

Happy to help! ;)