When a user accesses a specific Salesforce resource via a bookmark, email link, or browser autocomplete, Salesforce detects that the user needs to authenticate and redirects them to their SAML (Security Assertion Markup Language) Identity Provider (IDP). Along with the SAML authentication request, a form parameter called RelayState is passed to the IDP. RelayState controls where users are redirected after a successful login when using SAML 2.0.
Issue: If the RelayState value returned from the IDP is NULL in the SAML response, the user is redirected to the Salesforce Home page by default instead of the originally requested resource.
/00O/0, which is the object key prefix for Salesforce Reports. After successful sign-on, the user is automatically redirected to the Reports tab in Salesforce./00O/0. The IDP responds and Salesforce completes the SAML handshake. The user lands on the Reports tab because /00O/ is the Salesforce key prefix for the Reports object.| Post | https://xxxxxxx.mysalesforce.com/idp/login?xxxxxxxxx | SAML |
| Post | https://xxxxxxx.my.salesforce.com/?so=xxxxxxxxx | SAML |
In the above example, "/00O/ is the object key prefix to reports. After successful sign on, user is automatically redirected to Reports tab in salesforce.
Note: Salesforce does a POST request, so check your IDP url that is provided by your IDP is not doing a GET request. Else, Relaystate param will be returned as NULL.
If the RelayState is returned as NULL, consider changing the Service Provider Initiated Request Binding from HTTP Post to HTTP Redirect in the Salesforce Single Sign-On settings, and update the Identity Provider login URL accordingly.
Example scenario: A user receives an email with a link to an Opportunity record. If the user is not logged in, clicking the link redirects them to the Salesforce or SSO login screen depending on the org's login settings. After successful SSO authentication, the user expects to land on the Opportunity record. However, if RelayState is NULL, the user is redirected to the Home page instead. Changing the Service Provider Binding to HTTP Redirect resolves this issue and ensures the user is redirected to the correct Opportunity record.
Developer Doc: Implementing Single Sign-On Across Multiple Organizations
000388029

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.