Lorixen.

Feedback Surveys: Who May Respond, and Can They Answer Again?

Before adding a feedback survey to a customer portal, decide who may answer, whether a response is tied to an identity and what happens on a second visit. These are separate decisions. A survey that does not ask for a name is not automatically anonymous, and an invitation is not automatically proof that the intended person answered.

The useful brief describes the respondent journey and the evidence staff may see. It should not begin with a promise of trustworthy results based only on a form and a chart.

Choose an audience before sharing a link

A public link suits an open request for feedback, but it can be forwarded. An invitation-only survey has a different eligibility rule. Say whether the intended audience is anyone who finds the page, customers with an eligible transaction or a specific invited group. Do not label those audiences interchangeably in the results.

The Odoo 19 survey documentation illustrates separate settings for anyone with a link or invited people only. It also offers a login requirement that applies even to someone with a valid token. These are product examples of distinct controls, not a claim that every survey platform verifies a respondent's real-world identity.

In a commissioned app, ask what a forwarded invitation can do. Should a recipient sign in with the invited account, or does possession of the link suffice under your chosen policy? If eligibility cannot be established, show an explanation and a support route rather than silently accepting a response under someone else's name.

Describe identity honestly

Decide whether staff need named follow-up or only grouped feedback. Then specify which identifying information is stored with the answers, what administrators and exports reveal, and what the respondent is told before starting. Have the relevant privacy and security decisions reviewed separately.

Do not call a survey anonymous merely because its visible questions omit a name field. A login, invitation reference, export or other stored metadata may still permit association with a person. Conversely, do not collect unnecessary identity just to make a dashboard look more complete.

If you need completion tracking without exposing answers to the same staff, state that separation as a requirement and ask the developer to demonstrate it. It is not a feature established by the cited participant settings.

Define what another visit means

Choose whether a participant can submit once, replace a previous response or contribute several separately counted responses. Odoo documents a configurable attempt limit, but a limit alone does not define your reporting policy or establish one unique human per response.

For a fictional customer survey, suppose a respondent corrects an answer after submission. Decide whether the report shows the latest response, both versions or no edit at all. A page refresh must not unexpectedly count as a new customer. Equally, an intentional second response must not overwrite the first if your brief requires separate submissions.

Make the receipt clear: received, editable until a stated point, or final under the agreed rule. A saved draft is not a completed response. Survey closure also needs a rule for someone already halfway through; do not improvise it after publishing the link.

Test the respondent journey and the report together

Use invented accounts in the acceptance tests. Open a public link, forward an invitation, sign in with a different eligible or ineligible account, revisit after submission and try again after closure. Check the resulting records and report totals, not only the confirmation screen.

Inspect what a normal reviewer and an export recipient can actually learn about the respondent. Compare that with the promise shown before the survey. Test a correction and a saved-but-unsubmitted draft so neither changes the report in an unexplained way.

Bring the questions, intended audience and follow-up process to a survey or customer-portal discussion. Access, identity and repeat-response rules should support the feedback decision you intend to make. The workflow recommendations here are requirements to agree and test, not privacy certification or a guarantee that responses represent all customers.

WhatsAppLet’s talk