The survey lifecycle
- Draft — editable, invisible to users. Everything starts here.
- Published — targeted users are prompted on their next page load. The text is fingerprinted at this moment, and that fingerprint is what every response records.
- Archived — prompting stops. Existing responses are untouched.
Reusing a survey
Clone, in the row menu, copies a survey and its questions — body, type, enforcement, audience, pacing and window all come across. The copy is titled “… (copy)” and always arrives as a draft at version 1, with no publish date and no content fingerprint.
Use it to run the same rating survey each quarter, to trial reworded terms beside the current ones, or to reuse a carefully targeted audience without rebuilding it.
Clone or bump the version? Clone when you want a separate instrument that keeps its own answers. Bump the version when it is the same obligation and you need everyone to agree again — see below.
Writing a prompt people will answer
- Keep optional surveys to one or two questions. Response rates fall off a cliff after that.
- Say why you are asking in the message. “We are deciding what to build next quarter” earns more answers than a bare rating widget.
- For required surveys, put the whole obligation in the text. The person is agreeing to what is on screen, and that is what gets fingerprinted — not a linked document elsewhere.
- Write the question as a question. “How would you rate ERPat this month?” not “Rating”.
Versioning: when to bump
Editing a published survey changes what new people see. Ticking Publish as a new version does something much bigger: it invalidates every answer already given and asks everyone again.
| Change | Bump the version? |
|---|---|
| Fixing a typo or a broken link | No |
| Clarifying wording without changing the obligation | No |
| New clause, changed obligation, new data use | Yes |
| Annual re-acknowledgement of an unchanged policy | Yes |
Keeping optional surveys polite
Three settings control how often someone is bothered. They apply to optional surveys only; a required survey ignores all of them and keeps asking until it gets an answer.
| Setting | Default | What it does |
|---|---|---|
| Snooze (days) | 7 | How long “Not now” holds the prompt back. |
| Cooldown (days) | 30 | Quiet period after the person answers anything. |
| Max prompts | 0 (unlimited) | Hard ceiling on how many times they are ever asked. |
Users also have their own escape hatch: Don’t ask again opts them out of that survey permanently, across every future version. That is intentional — an optional survey somebody has explicitly refused is not one worth asking again.
Reading the responses
The Responses page is the ledger. Filter by survey, by outcome, or by date.
| Outcome | Means |
|---|---|
| Agreed | Accepted a required prompt, or submitted one. |
| Declined | Explicitly refused. A deliberate, recorded choice. |
| Answered | Completed an optional survey. |
| Opted out | Chose “Don’t ask again”. Not an answer to the question. |
Each row shows the person as they were when they answered — not as they are now. If someone changes their name or leaves, the record of what they agreed to stays accurate.
Opening one survey in full
Click a survey’s title on the Surveys page, or pick View from its row menu. The survey page collects everything about that one instrument in a single place:
- The definition — who it targets, when it runs, its pacing, its category, and the content hash recorded when it was published.
- Four counters — total responses, how many of those answered the version that is live today, the agreement rate, and when the last one arrived. The first two differ whenever you have bumped the version: that gap is how far the re-ask has got.
- The question breakdown — how everyone answered each question, across every version. An option nobody chose is shown at 0% rather than left out, because “nobody picked this” is a result too.
- Recent comments — the latest written answers, if the survey asks for any.
- Its own ledger — every response to this survey, filterable by outcome and date.
Reading one person’s answers
The eye icon at the end of any ledger row — on the Responses page or on a survey’s own page — opens that single response in full: who answered, which version they saw, what they said to each question, and the evidence recorded at the time (timestamp, IP address, browser and the hash of the exact text that was on screen).
For a required consent notice, that block is the point: it is what lets you show, later, precisely which wording a named person accepted and when. If a response was given to an older version, it is labelled Superseded so you are never comparing answers to two different texts without noticing.
A consent notice usually lists no per-question answers — the decision is the outcome at the top — and an opt-out records none at all. The modal says which case you are looking at rather than showing an empty box.
Watching the numbers
Overview gives you acceptance rate and response counts. A required survey’s acceptance rate is the number worth watching: a high decline rate usually means the text is unclear or is asking for something people are not willing to give.
On the main database the Overview also carries the app-rating tile and the Mobile app ratings card (average, star distribution, by-app and by-platform). Those are platform-only — see below.
Ratings from the mobile app — platform only
App ratings are a fleet dataset stored in the main database, so nothing about them appears inside a tenant workspace: no Rating Details page, no rating tile, no ratings card on the Overview. A tenant admin cannot act on them, and historical ratings cannot be attributed to a tenant at all (rows recorded before 1.1.0 carry no tenant), so a per-workspace view of them could not have been accurate either.
Rating Details lists what users submitted through the mobile app, filterable by app, platform, star value and date. Which apps can be rated is decided in the App Library (the Applications module): a published app accepts ratings (apps with admin-only or hidden visibility stay off the rating surface), and unpublishing it stops new ratings while keeping the history. The old in-module App Catalog was retired in 1.6.0.