Trusted URLs for Redirects
A Trusted URL for Redirects is an entry on the Trusted URLs for External Redirects allowlist in Salesforce Setup.
Definition
A Trusted URL for Redirects is an entry on the Trusted URLs for External Redirects allowlist in Salesforce Setup. It names an external destination that Salesforce is permitted to send a user to when a link, custom button, or formula field points off the platform. Together these entries form the allowlist that the platform checks before it bounces a user to any outside address.
The feature exists to stop open redirect abuse. Without an allowlist, an attacker can craft a link that starts on your trusted Salesforce domain and then forwards the victim to a malicious site. By approving destinations ahead of time, you decide exactly where outbound redirects may go, and Salesforce can warn or stop anything that falls outside the list.
How Salesforce decides where it is safe to send a user
What an open redirect actually is
An open redirect is a flaw where a legitimate page accepts a destination in a URL parameter and forwards the visitor to it without checking the value. The starting address looks trustworthy because it is your real Salesforce domain. The victim sees a familiar host, clicks, and lands somewhere the attacker controls. Phishing campaigns love this pattern because the bait carries a brand the target already trusts. Salesforce pages and custom links can produce outbound redirects in normal use. Payment gateways, support portals, and vendor integrations all need users to leave the org and arrive somewhere external. The risk is not the redirect itself. The risk is an unchecked redirect that any crafted link can ride. Trusted URLs for External Redirects closes that gap by turning outbound destinations into a deliberate, reviewed list. If a target is not on the allowlist, the platform treats the redirect as suspect and applies your configured response instead of forwarding silently.
Where the setting lives and what it covers
You manage these entries from Setup. In the Quick Find box, enter Trusted URLs for External Redirects, then open that page and click New URL to add a destination. The page sits within the session and browser security area, alongside the related Manage Redirections to External URLs controls. Each entry is one approved external address that outbound links may reach. The allowlist governs redirects that originate from hyperlinks in your data, including links rendered through custom buttons, formula fields, and similar link surfaces. Salesforce checks the first hop out of the platform against your list. It cannot inspect every later hop once the browser has left Salesforce, so an approved destination that itself forwards elsewhere is outside the platform's view. That limit is worth remembering when you approve a domain that you know chains to other sites. Approve destinations you actually trust to land users, not just transit them.
Warn the user or block the redirect
For links whose target is not on the allowlist, you choose how Salesforce responds. The platform can warn the user before sending them onward, or it can stop the redirect outright. Salesforce recommends warning users during these redirections rather than blocking by default, because a hard block can break a legitimate integration that an admin simply forgot to add. The warning behavior differs by interface. For users on Salesforce Classic, the warning message can include an option to trust the URL going forward, which lets a person whitelist a destination at the moment they hit it. Lightning Experience does not offer that per-user trust prompt. Plan your rollout around that difference. If most of your users are on Lightning, the practical model is that admins curate the allowlist centrally, and users see a warning interstitial for anything outside it. Treat the warning page as a signal to review, not as a nuisance to suppress, because each warning is a redirect your org did not pre-approve.
Field type changes what is protected
The protection does not apply uniformly across every field. The behavior depends on whether the hyperlink comes from a URL field or from a Long Text Area field, and on which interface the user is in. For the URL field type, Salesforce can restrict redirections from hyperlinks for users on both Lightning Experience and Salesforce Classic. That is the broader coverage. For the Long Text Area field type, the restriction applies only to users on Salesforce Classic. A hyperlink embedded in a Long Text Area value will not get the same redirect check for a Lightning user. This gap matters if your org stores clickable links inside long text fields and assumes the allowlist is guarding them everywhere. It is not. When you audit where outbound links live in your data model, note any Long Text Area fields that hold URLs, and recognize that Lightning users following those links are not covered by this control. Where possible, move user-facing outbound links to URL fields so the allowlist check applies in both interfaces.
Seeing what got blocked
When Salesforce blocks a redirect because the target was not trusted, it records the event. Blocked redirections appear in the Trusted URL and Browser Policy Violations list in Setup, the same place that surfaces content security policy violations. The list holds entries from roughly the last seven days, so it is a rolling window rather than a permanent log. That violations list is the practical feedback loop for this feature. After you turn on blocking or warning, watch the list to learn which real destinations your users actually need. An entry there is either a legitimate integration you should add to the allowlist or a genuine attempt to push users somewhere they should not go. Reviewing it regularly keeps the allowlist accurate without forcing you to predict every destination up front. Because the window is short, build the review into a routine rather than treating it as a one-time check. If you need a longer record, capture the entries on your cadence before they age out of the seven-day window.
Cross-org redirections and Salesforce-to-Salesforce
Not every external destination is a third party. Many organizations run more than one Salesforce org and need links that move users between them, such as a link from a sandbox to production or between two production orgs. Salesforce treats another Salesforce org as an external destination for redirect purposes, so those hops also need to be trusted. To allow them, you identify the cross-org URLs your users move through and add them so redirections to your other Salesforce orgs are permitted. Salesforce has shipped a release update in this area to require that cross-org redirections go only to trusted orgs, which tightens the same allowlist model across org boundaries. The takeaway for an admin is to map your real multi-org link paths before enforcement applies. Walk the buttons, list links, and bookmarks that send users from one org to another, confirm each destination, and add the trusted orgs. Doing that ahead of any enforcement deadline keeps internal navigation working while still closing the open redirect door for genuinely untrusted targets.
Fitting it into your security baseline
Trusted URLs for External Redirects is one control in a wider browser and session security story. It pairs naturally with Trusted URLs (the content security policy allowlist), My Domain, and the violations list, and Salesforce Health Check can help you keep the broader posture honest over time. Treating these as a set, rather than as isolated switches, gives you a coherent answer to how outbound and embedded content is governed in your org. The work is mostly discipline, not difficulty. Decide the destinations you genuinely trust, document why each one is on the list, and review on the same cadence you use for the CSP Trusted URLs. The configuration cost is small. The cost of carrying an unmanaged open redirect is not, because it shows up in security reviews, packaging reviews for ISVs, and real phishing incidents. Set the behavior to warn while you learn your traffic, watch the violations list, then tighten toward blocking once the allowlist reflects your real integrations.
How to add a trusted redirect URL in Setup
Add an approved external destination to the Trusted URLs for External Redirects allowlist so Salesforce permits outbound redirects to it. You do this in Setup, one URL at a time.
- Open the Setup page
From Setup, type Trusted URLs for External Redirects in the Quick Find box, then select that page. It sits with the session and browser security controls.
- Start a new entry
Click New URL to create a single allowlist entry for one external destination your users are redirected to.
- Enter the destination
Type the external URL you want to trust, then save. The entry becomes a destination Salesforce will allow outbound redirects to reach.
- Choose the response for untrusted targets
Set whether Salesforce warns the user or blocks the redirect when a link points to a target that is not on the list. Salesforce recommends warning while you learn your traffic.
- Validate against real links
Click through your custom buttons, list links, and formula-field links to confirm trusted destinations work and untrusted ones get the response you chose.
The external destination you are approving for outbound redirects. Approve hosts you trust to land users, not just pass them onward.
Whether non-trusted targets trigger a user warning or a hard block. Warn is the gentler rollout; block is stricter.
- Salesforce verifies only the first hop out of the platform. It cannot check later redirects once the browser leaves Salesforce, so a trusted host that forwards onward is outside the allowlist's view.
- The per-user option to trust a URL at the warning prompt exists in Salesforce Classic, not Lightning Experience. In Lightning, admins must curate the list centrally.
- Long Text Area field links are protected only in Salesforce Classic. Lightning users following links in Long Text Area fields are not covered, so prefer URL fields for outbound links.
- Blocked redirects show in the Trusted URL and Browser Policy Violations list for only about seven days. Review it on a routine, or capture entries before they age out.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Trusted URLs for Redirects.
Hands-on resources to go deeper on Trusted URLs for Redirects.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the primary benefit of Trusted URLs for Redirects for Salesforce administrators?
Q2. In which area of Salesforce would you typically find Trusted URLs for Redirects?
Q3. Can a Salesforce admin configure Trusted URLs for Redirects without writing code?
Discussion
Loading discussion…