Specifications

Users

Participant

Respondent

• Participants should have limited access to only their assigned questionnaire
• We can generate unique, time-limited access tokens for each participant
• Tokens can be sent via email or SMS, and used for authentication instead of traditional username/password
• Participant tokens should expire after a set period or once the questionnaire is submitted or when the survey end date is reached

Interviews Admin (super-validator)

Super-validator who can monitor interviews, get interview stats, validate interviews,

• Admins require the highest level of access and permissions
• Implement a secure login process with strong password requirements and two-factor authentication (2FA)
• Use role-based access control (RBAC) to define and manage admin permissions
• Log and audit all admin actions for accountability and security monitoring
• Consider implementing IP whitelisting or VPN requirements for admin access

Systems Admin

Administrator for the databases, error management, bug monitoring, etc.

• Admins require the highest level of access and permissions
• Implement a secure login process with strong password requirements and two-factor authentication (2FA)
• Use role-based access control (RBAC) to define and manage admin permissions
• Log and audit all admin actions for accountability and security monitoring
• Consider implementing IP whitelisting or VPN requirements for admin access

Validator

• Validators need access to the validation interface and the ability to modify respondent interviews
• Use a secure login process similar to admins, with password complexity and 2FA
• Define specific validator roles and permissions using RBAC
• Restrict validators to only access interviews assigned to them for validation
• Implement auditing and change tracking for all validator actions on interviews

Interviewer

Third-party person who helps respondents start their interview on the phone, by chat or using videoconference. They may start an interview from scratch and complete them without the respodnent having to log in, or they can help the respondent log in after entering some information. They may also be able to get into an existing interview to help the respondent fill out next sections or they may complete the interview after the respondent completed previous sections.

• Interviewers require access to start new interviews or modify existing ones on behalf of respondents
• Implement a secure login process with password complexity and 2FA
• Define interviewer roles and permissions using RBAC
• Assign interviewers to specific interviews or respondents
• Log and audit all interviewer actions, including starting, modifying, and submitting interviews

Login methods

Email-based login

• When a respondent provides their email, check if the email already exists in the database
• If the email is not found:

• Generate a unique, secure token associated with the respondent's email and questionnaire
• Create a new respondent account in the database, associating it with their email and the generated token
• Start a new session for the respondent using
• Redirect the respondent directly to their questionnaire page

• If the email is found:

• Generate a unique, secure token associated with the respondent's email and questionnaire
• Update the respondent's account in the database with the new token
• Send the token to the respondent's email as a secure link
• When the respondent clicks the link, validate the token and start a new session

• If the respondent returns later or uses a different device, they can re-enter their email to receive a new secure link

OAuth login

• Use OAuth support to implement login via Google, Facebook, Apple, or other providers
• Configure the necessary OAuth settings (client ID, client secret, redirect URLs) for each provider
• When a respondent initiates an OAuth login, redirect them to the provider's login page
• Upon successful authentication, retrieve the respondent's OAuth token and profile information
• Create or update the respondent's account in the database, associating it with their OAuth identity
• Start a new session for the respondent

Anonymous login

• When a respondent chooses to log in anonymously, generate a unique, temporary session token
• Store the session token securely, with a limited expiration time
• Associate the session token with the respondent's questionnaire ID in the database
• If the respondent's session ends or they navigate away, their progress will be lost and they will need to start a new anonymous session

Secure link/token login

• When a respondent's email is included in a survey invitation or reminder, generate a unique, secure token associated with their email and questionnaire
• Store the token securely in the database, along with the respondent's email and questionnaire ID
• Include the secure token in the email sent to the respondent as a clickable link
• When the respondent clicks the link, validate the token and start a new session
• If the respondent returns later or uses a different device, they can re-use the same secure link to continue their session