Skip to content

Participants, SSO, and verification

A question that comes up as soon as a workspace turns on single sign-on: does SSO now cover the people answering our surveys?

No. The two systems do not meet, and understanding why saves a lot of confusion about what a “verified” response actually means.

Seat Holders sign in to the workspace. They have accounts, they consume seats, and when SSO is configured your identity provider decides whether they get in.

Participants answer surveys through a link. They have no workspace account and no seat, and they never reach a sign-in screen — so there is nothing for your IdP to authenticate. Enforcing SSO changes nothing about how anyone answers a survey.

This is deliberate. Requiring survey participants to exist in your directory would rule out the audiences surveys are most useful for: contractors, customers, candidates, people at a partner company, or anyone whose honesty depends on not being in your directory at all.

Participant Verification proves control of an email address. ScatterSpoke emails a signed link; clicking it establishes that whoever is answering can read mail at that address.

That is a narrower claim than SSO makes, and it is worth being clear about the difference:

  • SSO says this person exists in your directory and your IdP let them in today.
  • Verification says this response came from someone who can read mail at this address.

Verification does not check the participant against your directory, apply your IdP’s access policies, or consult group membership. If your survey audience needs to be restricted to directory members, restrict who receives the link — the survey page cannot do it for you.

Not every link asks. Verification is required only when all of these hold:

  • The distribution collects in verified mode, which is the default.
  • The link is a real distribution, not a preview link.
  • The link is not bound to a specific recipient.

That last condition explains the most common surprise. A per-person email invite already carries the recipient’s identity in the token, so ScatterSpoke recognises them on arrival and shows no gate at all — the participant is identified more strongly than one who typed an email address, not less. It is the shared, reusable entry link that has to ask.

Anonymous collection makes the email gate optional, and preview links never verify.

A participant who verifies keeps a remembered participant session in their browser. Later verified surveys from any workspace recognise it and skip the gate — the team answering a daily standup survey verifies on day one and not again.

The relevant lifetimes:

TokenLifetime
Participant verification link24 hours
Resume link, emailed to continue an unfinished response7 days
Cross-survey participant session90 days

All three are cryptographically signed rather than stored as guessable strings, and each type is bound to its own purpose so one cannot be replayed as another.

These two are independent, and conflating them is the other common mistake.

A verified participant can still be anonymous to Seat Holders in reporting. ScatterSpoke knows the response is genuine — one real person, one address, not a bot filling the form fifty times — while showing you nothing about who wrote it.

So “we need verified responses” and “we need anonymous responses” are not in tension. You can, and usually should, have both.