The tl;dr
After each send cycle, the token is rotated. The dispatch is updated with a new value — xK9m… → mP7q… — so even with full database access, a response keyed to the old token can no longer be traced back through the dispatch record. The chain is broken at storage time, and again at rotation.
Overview
Relay's anonymity isn't a privacy policy or a setting that can be turned off. It's how the system stores information. This guide explains what that actually means: how responses are recorded, why the link between sender and response is broken by design, and what's visible to managers on the dashboard.
Two separate worlds
Relay operates two distinct systems that never directly communicate with each other: the sending system and the response system.
The sending system knows who's in your team. Names, contact details, channels. This is where Relay personalises the check-in message and routes it to the right phone number or inbox. That information is necessary to deliver the check-in, and it stays there.
The response system knows what was said, when it was said, and which survey it belongs to. It does not know who said it. By the time a response is stored, the sender's name, email address, and phone number are not part of the record. There's no field for them. They're not redacted or masked. They were never written there in the first place.
How the link is broken
When Relay sends a check-in, each dispatch is paired with a randomly generated token. This token has no relationship to the member's name, phone number, or email address. It's a unique, meaningless string generated at send time — its only job is to allow the system to associate an incoming response with the correct survey.
When a response arrives, the system records it against that token. Not against the person who held it. The response is stored with a survey ID, a timestamp, and the response body. Nothing in that record identifies its author.
After each send cycle, the tokens are rotated. New ones are generated for the next send. This means that even if someone with database access tried to trace a response back through the send record, the token that was used at the time of that response no longer exists on the dispatch in a form that connects them. The chain is broken at both ends: at storage time, and again at rotation.
For SMS and WhatsApp responses, Relay routes check-ins through hundreds of different sending numbers. An inbound reply cannot be used to infer the original sender's contact details. The routing layer is designed specifically to prevent that inference.
+- Sending System ------------+ +- Response System ----------+| | | || member | | raw || name - - - - - - - X | | token || contact - - - - - - X | | survey_id || | | body || dispatch | | || member_uuid (here only) | | conversation || contact (here only) | | body || token -------------------|------->| sentiment || | | |+-----------------------------+ +----------------------------+- - X blocked; NEVER reaches the response system Token: Random UUID not derived from any identity field Rotated after each send; the dispatch-response link is cutThe minimum threshold
Results only appear when enough people in a team have responded in a given week. If fewer than the minimum threshold respond, no results are shown for that period.
This is an anonymity protection, not just a data quality measure. In a small team, a very low score from two or three respondents could be narrowed down by process of elimination. A manager who knows roughly how people were feeling could use context to infer who said what. The threshold removes that possibility: below the minimum, there is simply nothing to see.
Absence is also protected. In a team of four, if three respond and one doesn't, that silence is itself information. The threshold means a manager won't see a result that could be explained partly by who didn't answer. This matters most in small teams, which are often the ones with the most at stake when it comes to trust.
What the dashboard shows
Managers see aggregated scores, movement over time, and a pool of anonymised comments. There are no names attached to responses. There is no list of who answered and what they said. There is no way to filter or sort by individual.
Comments appear as a collective feed. They may be specific — referencing a project, a process, or a particular week — but the dashboard provides no mechanism to trace a comment back to an individual. The specificity of the comment is useful signal. The identity of the person who wrote it is not available, because it was never stored.
The total number of recipients for each check-in is shown alongside results. This is deliberate: knowing how many people were in scope gives context for the scores and reinforces that responses came from a group, not an individual.
What it means for your team
None of this requires your team to understand the architecture. What matters to them is simpler: what they say in Relay won't be traced to them, regardless of whether their manager wants to know or is actively trying to find out.
This is a different promise than most tools make. Most tools promise that your employer won't look. Relay is designed so that looking isn't possible — not by accident or by policy, but because the information required to do it was never written down in a traceable form.
If a team member asks how they can verify this, the honest answer is: the design is the proof. The link they receive is keyed to a token, not their name. The response they send is stored against that token, not their identity. The token is cycled before it could be used to trace anything backward. And below the minimum threshold, there's nothing to see at all.
Anonymity works in Relay because the system doesn't need to know who you are to store what you said. The two things live in separate systems, with separate identifiers, and the identifier that connects them at send time is discarded before it can be used to trace a response back. That's not a feature you can configure. It's the architecture.