# Redirect node reference

You can send visitors to another page when they reach a Redirect node. See which URLs work, how new tabs behave, and when to forward visitor data.

Available on the Grow, Scale, and Pro plans.

**Redirect** sends visitors to another page when they reach the node. You can open that page in the same tab or a new one.

![Redirect editor with the example booking URL and new-tab and subscriber-data switches off](https://rightmessage.com/help/screens/flows-redirect-settings.light.webp)

## When to use it

Use a redirect when you want visitors to leave the current page automatically, such as after answering a quiz or submitting a form.

For example, [WorkForge](https://workforge.rightmessage.com) could send a qualified visitor to `https://workforge.rightmessage.com/contact.html` to get in touch. The destination page handles what happens next. A redirect doesn't book an appointment or jump into an arbitrary node in another flow.

## Settings

| Setting                               | What it does                                                                                                          | Default |
| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------- |
| **Redirect visitors to another page** | Sets the destination URL or supported path. When you leave the field, validation shows the first error.               | Blank   |
| **Open in a new tab?**                | Requests a new tab instead of replacing the current page. Browser popup rules still apply.                            | Off     |
| **Send subscriber data?**             | Adds RightMessage visitor context for a handoff to another domain. This appears only for absolute HTTP or HTTPS URLs. | Off     |

Changing the destination to a nonabsolute path clears **Send subscriber data?**. Leave forwarding off for a same-site destination such as `/pricing.html`.

### Accepted destinations

The editor accepts destinations that begin with `http://`, `https://`, or `/`, with no whitespace. A path such as `/contact.html` uses the current website's origin. A full URL such as `https://workforge.rightmessage.com/contact.html` specifies the website as well as the page.

URLs beginning with `//` aren't accepted. Neither are bare hostnames, `mailto:` links, or `javascript:` URLs. Use a real page on your website and check that it exists. The editor checks the URL's format, not the page itself.

RightMessage renders Liquid in the URL before navigating. Keep the required URL prefix and test the final destination with the data both present and missing.

### Forwarding visitor data

Forwarding carries the visitor ID, subscriber ID, and answered survey segments to another domain with the same RightMessage project installed. The destination can then recognize that context.

It doesn't install RightMessage on the destination, create an email contact, or make an unrelated booking service understand the data. Use forwarding only for a destination that's meant to receive it, not an arbitrary external link. [Visitor identification](https://rightmessage.com/help/how-do-we-identify-returning-subscribers-or-contacts) explains the recognition limits.

## How visitors move through it

Put required questions and data actions before the redirect. It ends the current flow's display path, even when it opens a new tab. Visitors won't continue through ordinary nodes below it.

For a form, place the redirect in **Post-Submit Actions For This Form**. A message before the redirect ends the path and prevents automatic navigation. See [form completion and redirects](https://rightmessage.com/help/form-completion-and-redirects).

Before navigating, the flow waits up to two seconds for pending email-platform synchronization, then schedules the redirect. That wait doesn't guarantee the external update succeeded. If the redirect follows a field or tag update, [check the contact record separately](https://rightmessage.com/help/verify-an-integration-change).

## Things to know

- Ordinary builder preview suppresses redirects. A preview that stays on the current page doesn't necessarily mean the destination is broken. Use an authorized on-site test, then check the published path separately.
- Debug sessions don't forward visitor context across domains. Check that handoff outside the debugger.
- RightMessage stops a redirect if its resolved destination is the current URL. Choose a different destination for a post-submit handoff.
- Test the same-tab or new-tab behavior you intend to publish. If the destination has a widget, check its eligibility separately. Arriving at the page doesn't bypass that widget's rules.