I'm unsure how to accomplish this use case in LimeSurvey.

When somebody visits our facility, if they have never visited before, they are registered on our internal web portal (they're given a profile with an e-mail address included). Currently, whether it was their first visit or not, everyone who visits is e-mailed a survey, which we created with LimeSurvey. The e-mail is just run from our web portal to see when their last visit was, and if it was today, sends them the LimeSurvey link from our mail servers.

The survey is ongoing with no end date, we review responses every once in a while.

At the moment, the survey is completely anonymous and untraceable.

We would like to change to a token system, so that a person can only fill it out once per visit. So, in the strictest sense of the word, we "know" the participants, but we cannot define a participants table as it is an ongoing survey where newcomers in the future would need to be included.

How could we go about prompting visitors to fill out the survey, with no end date, no predefined participant table, using a token system to allow only one response per person per visit? Is this possible?

Thanks for your time!

skis89 wrote: How could we go about prompting visitors to fill out the survey, with no end date, no predefined participant table, using a token system to allow only one response per person per visit? Is this possible?

Using a token system is demanding a list with tokens. This predefined participant list didn't need to have the emails or participants, but just a list of dummy tokens.

The are plugins to create a token during accessing the survey.
Check this one: gitlab.com/SondagesPro/SurveyAccess/registerQuick
I haven't used it yet. But the developer is reading this forum.

If you don't want to use a token system, you could create a hashcode from the emailadress and a salt via your webportal. That hashcode would be used as a URL parameter to be submitted from the webportal to LimeSurvey. You could transfer additional codes, which none could create without going via your webportal. That way you could identify the valid submissions inside a open survey.

Or you could use the API for creating an entry in the token table for each person that is created in your webportal.