By default, someone who finishes your survey stays on the PublicInput page and sees your confirmation message. You can instead send them on to a page you choose, on your own website or anywhere else.

Feedback is rarely the reason someone was online in the first place. They were doing something else, and you interrupted them to ask. The redirect puts them back where they were.

Take a parks and recreation team running registration through recreation management software. A season of youth soccer wraps up, and the confirmation email that goes out to families includes a short feedback survey about the program.

A parent clicks through from the recreation software into the survey, answers three questions about coaching, scheduling and facilities, and submits. Without a redirect they land on a PublicInput confirmation page and the trail ends there. With one, they land back in their account in the recreation software, on the page listing programs open for registration.

The parent has just told you what they thought of the last session, and is now looking at the next one. That is a better ending for them and a better one for the department.

The same shape works anywhere feedback is attached to a transaction someone was already in the middle of:

Returning people to your own site. If the survey was reached from a project page on your city or agency website, sending people back there keeps them in your own content rather than leaving them on a dead end.

Pointing people at the obvious next step. A rate-review survey can end on the page explaining the hearing schedule. A budget survey can end on the page listing upcoming public meetings.

Working with a research panel. If a polling or panel firm is recruiting respondents for you, they will give you a completion URL. Sending respondents back to it is how the panel knows the person finished and should be credited. This is a standard requirement for panel work. Most panels also need their own respondent id handed back on that URL. See Sending back a value from the survey link below.

The redirect is set per project.

Immediately sends people to your page as soon as they submit. They do not see the PublicInput confirmation. Use this when the page you are sending them to does its own thank-you, which is usually the case when you are handing back to another system.

After showing the confirmation shows your confirmation message first, waits the number of seconds you set, then moves them on. Participants get a control to continue straight away or to stay on the page. Use this when your confirmation message says something the participant needs to read, such as what happens next or who to contact.

You can include merge fields in the redirect URL. They are replaced with the real values at the moment the person submits, and are encoded for you so you do not have to worry about spaces or punctuation.

The built-in fields are:

Any custom participant attributes you have set up also appear in the list, as {{attr-...}} fields. If you store an account number or a household reference as a participant attribute, that is how you pass it on. The list in your own account shows your own attribute names. See Participant Information for setting those up.

The list also shows {{param-pid}}. That one is an example of a pass-through value, covered in the next section.

So a redirect back into recreation software might look like this:

https://register.example.gov/my-account/programs?ref={{user-id}}

Passing an identifier matters when the receiving system needs to know who arrived. A recreation platform that gets {{user-id}} can drop the parent straight into their own account rather than a login screen.

Sometimes the system that sends people to your survey has its own id for them, and needs that id back when they finish. A research panel is the usual case. It links each respondent in with the panel's own respondent id, and credits them when the same id comes back on the completion URL. {{user-id}} cannot do this, because it is PublicInput's id for the respondent, which the panel has never seen.

Pass-through values handle it in two steps.

When that respondent submits, they are sent to https://panel.example.com/complete?rid=ABC123.

In practice the panel does the first step. When they ask for your survey link, give it to them with ?param-pid= on the end and ask them to add each respondent's id after it. Panels have a standard way to do this. Send people to the PublicInput survey link itself, with the value on it.

You can use any name after param-, and more than one at once. A survey link ending ?param-pid=ABC123&param-wave=2 fills both {{param-pid}} and {{param-wave}}. A link can carry pass-through values and pre-filled answers together. See Pre-fill a survey answer from a link.

If a respondent reloads the page partway through the survey, the value is kept.

The URL must start with https. Plain http is rejected. Response details can travel in this link, so it is not sent in the clear. If you paste an address that is not valid, you are told when you save rather than finding out later that the redirect never fired.

Merge fields go in the path or the query of the URL. They cannot be part of the web address's domain, so the site people are sent to is always the one you typed.

Pass-through values are checked strictly. They arrive on a link anyone can edit, so a value may contain only letters, numbers, hyphens, periods, underscores and tildes, up to 128 characters. A name may contain letters, numbers, hyphens and underscores, up to 32 characters. A value that breaks these rules is dropped rather than trimmed, and its merge field is left empty. Sending a panel an altered id would be worse than sending none. Up to 10 pass-through values are passed along from one response.

Think about what you put in the link. Merge fields can carry a respondent's email address and IP address to another system. Only include what the receiving system genuinely needs, and only send it somewhere you would be comfortable defending in a public records request. This matters more, not less, when the receiving system belongs to another department or an outside vendor. Pass-through values are whatever the sending system put on the link. PublicInput checks their characters, not their meaning.

The redirect waits for follow-up questions. If your survey collects demographics or Title VI follow-up questions after submit, participants are not redirected while that is still open. Those responses are a civil rights reporting record and are not skipped.

Staff data-entry sessions are excluded. If your team is entering responses on someone's behalf, they stay on the page instead of being bounced out to the redirect after every entry.

Post-submission redirects are available on the Engage Plus plan family. If the option is not visible in your submit settings, contact your account manager.