Loading
Feature Disruption - Service Cloud VoiceRead More
Feature degradation | Gmail Email delivery failureRead More
Set Up and Maintain Your Salesforce Organization
Table of Contents
Filter by (0)Add
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

            Search all of Salesforce Help
            Search all of Salesforce Help
            Identify Cross-Org Urls to Allow for Redirections

            You are here:

            1. Salesforce Help
            2. Docs
            3. Set Up and Maintain Your Salesforce Organization

            Identify Cross-Org Urls to Allow for Redirections

            To protect your users from potential attacks, users aren’t redirected to a different Salesforce org from your Salesforce org unless the URL is trusted. This limitation includes redirections to the second org’s publicly served pages and content. To allow a link, action, or process to redirect the user to a different Salesforce org that you own, add the target URL to the Trusted URLs for Redirects allowlist.

            Required Editions

            Available in: all editions
            User Permissions Needed
            To view, filter, and delete Trusted URL and Browser Policy violations: Customize Application AND Modify All Data
            Access the Blocked Redirect event type object:

            View Event Log Files and API Enabled

            OR

            View All Data

            Review When Redirections Are Restricted

            Not every URL for your other Salesforce orgs requires an entry on the Trusted URLs for Redirects allowlist. To learn where the allowlist applies, see External Redirection Restrictions in Salesforce.

            What Qualifies as a Cross-Org Redirection

            Cross-org redirections are a special type of redirection that occurs when the user is redirected from one Salesforce org to another org. For example, when the user is redirected from production to a sandbox.

            Some cross-org redirections are also cross-origin redirections, meaning that they point to another domain. For example, from MyDomainName--UAT.sandbox.lightning.force.com to MyDomainName.my.salesforce.com. Others point to the same root domain, such as force.com in a redirection from MyDomainName--UAT.lightning.force.com to MyDomainName--UAT.sandbox.lightning.force.com. In all cases, the user is redirected away from the originating org to another Salesforce org.

            Determine the Specific Cross-Org URLs to Trust

            Now that you understand cross-org redirections and when those redirections are blocked, find the cross-org URLs to allow for redirections from your org.

            Warning
            Warning To protect your users, we strongly discourage adding top-level Salesforce domains, such as *.salesforce.com, *.force.com, or in this case, *.file.force.com, to the Trusted URLs for Redirects allowlist.
            1. To identify blocked cross-org redirections, filter the Trusted URL and Browser Policy Violation list in Setup.
              1. In Setup, find and select Trusted URL and Browser Policy Violations.
              2. Filter the list.
              3. For Field, select Untrusted URL.
              4. For Operator, select contains.
              5. For Value, enter .force.com, .forceusercontent.com, .force-user-content.com, .salesforce.com, .salesforceliveagent.com, .salesforce-experience.com, .salesforce-hub.com, .salesforce-scrt.com, .salesforce-setup.com, .salesforce-sites.com, .sfdcopens.com, .site.com, .trailhead.com.

                Alternatively, you can search for each of those domains in the BLOCKED_URI_DOMAIN field on the Blocked Redirect event type.

              To understand where each of these domains is used, see Allow the Required Domains.

              Note
              Note the Trusted URL and Brower Policy Violations list includes blocked redirections that occurred within the last seven days. To track blocked redirections over time, schedule a daily query of the Blocked Redirect event type. To understand which blocked redirections Salesforce tracks, see External Redirection Restrictions in Salesforce.
            2. To determine where the blocked redirection originated, use the ORIGIN field on the Blocked Redirect event type object.

              For example, if a form on an Experience Cloud Visualforce site page redirects a user to an untrusted URL via the saveURL parameter, ORIGIN contains the base URL of that site. This information isn’t available in the Trusted URL and Browser Policy Violations list in Setup.

              Tip
              Tip The blocked redirect event is free for all customers with a 24-hour data retention period. The event is available in the API but not in the Event Monitoring Analytics app. To collect details for blocked redirections over multiple days, schedule a daily query of the Blocked Redirect event type via REST API.

              See Blocked Redirect Event Type in Object Reference for the Salesforce Platform.

            3. To avoid unnecessary redirections, update incorrect links.
              If you use hard-coded links, that link can be copied from production to a sandbox, resulting in an incorrect URL. For example, on a Visualforce page in a sandbox, you find a link to a file that lives in production. To link to the file in the sandbox instead, update the link to use the corresponding sandbox URL. Use relative or dynamically generated URLs whenever possible.
            4. If you set the Allow redirections to untrusted external URLs field in Session Settings to Never, consider allowlisting all URLs for your other Salesforce orgs.
              With that configuration, redirections from hyperlinks in URL and Long Text Area fields in Salesforce are blocked unless the target URL is on the Trusted URLs for Redirects allowlist. Also, those blocked redirections aren’t captured in the Trusted URL and Browser Policy Violations list. If you allowlist all the URLs for your other Salesforce orgs, you can reduce end-user frustration and potential broken functionality.
            5. Include your custom domains in the list of URLs to allow.
              A custom domain is a domain that you own, such as https://www.example.com, that serves content from your Experience Cloud sites or Salesforce Sites. You can find your custom domains on the Domains page in Setup.
            6. Collect a list of the cross-org URLs to allow.

              These formats are accepted in the Trusted URLs for Redirects allowlist: example.com, *.example.com, and https://example.com.

              If you use a wildcard to allow redirections to your other Salesforce orgs, make sure that the value after the wildcard is unique to the org that you trust. Usually this approach requires that the trusted URL includes the My Domain name of the trusted org. For example, to trust https://MyDomainName.file.force.com, trust the full URL or *.MyDomainName.file.force.com.

            See Also

             
            Loading
            Salesforce Help | Article