Contact about a response

Use this when you want to ask a follow-up question or discuss someone's feedback. You offer contact, and the respondent chooses whether to accept. They can submit feedback without accepting contact.

Contact is available in the widget and the current survey-site hosted and embedded pages. Legacy Next.js survey pages do not offer this contact step. It is in a limited rollout for organizations in the standard allowlisted cohort; the setting appears only when Response contact is enabled for your organization. Organizations outside the rollout cannot enable contact through custom submissions.

Offer contact

In the flow's Settings, turn on Offer contact about this response, then publish the flow. The setting is off by default. Each published version keeps its own setting.

After submitting, respondents can choose Yes or No. If an email is already available, Yes can use it without another email form. Otherwise, they can enter an address. Use a different email lets them choose another address.

An address entered for contact takes priority over the current frontend email trait, which takes priority over an eligible server-held email trait. An invalid or cleared current address asks for entry instead of falling back to an older address. Email identifiers alone are not a list of contact destinations.

Server-held addresses are never shown in the widget, including masked versions. Server lookup requires your existing verified app JWT context and eligible integration evidence. A public app key or unsigned user ID cannot authorize it. Your existing SDK identify() signature and JWT setup remain the same.

Custom submissions

If you implement your own submission interface, send the respondent's decision in the response submission's optional contact field:

{ "contact": { "accepted": true, "email": "respondent@example.com" } }

Omit email to use the current eligible contact address. If your custom client already knows a frontend email trait, pass it separately as frontendEmail; the server does not derive contact from your identities array. The SDK supplies this value automatically.

To decline, send { "contact": { "accepted": false } }. Omitting contact grants no permission. The server also checks that the submitted flow version offers contact.

Inspect the successful submission's contact.status. Only accepted confirms that contact was enabled. Feedback can succeed while contact still needs an address. If the status is address_required, ask for an email, then call responseContact.record with the returned token:

{"token": "RETURNED_CONTACT_TOKEN","contact": { "accepted": true, "email": "respondent@example.com" }}

Use the same app scope and authentication as the original submission. An offered state also carries a token for collecting the decision after submission. Retain the original submission's frontend email and authentication context for this step, even if your application identifies another user meanwhile. declined records refusal; absent contact state does not confirm permission. The completion call returns accepted, declined, address_required, or an error status. Do not resubmit the feedback to retry this optional step.

Keep permissions separate

Contact permission does not grant respondent analytics consent or link the response to a rich user profile. A contact address selected for the conversation does not update the user's profile or identity records. Later general email trait updates do not redirect that conversation's contact address.

The first accepted address stays fixed for that conversation. Repeating the same choice is safe; a later completion call cannot replace it with another address. Respondents can withdraw contact permission without changing that saved address.

A submission confirmation receipt is a separate choice. Requesting a receipt, or answering an ordinary email question, does not permit follow-up contact.