Overview
If your organization enforces Single Sign-On (SSO) through Okta, users authenticate into HG Insights by logging in through Okta rather than entering Salesforce credentials directly. Okta then routes that login to a specific Salesforce account behind the scenes. If a user reports that the Salesforce connection is pulling data as, or acting under, an unexpected Salesforce identity, the cause is almost always this Okta-to-Salesforce user mapping — not the Salesforce connected app.
This is a separate issue from the ones covered in Troubleshooting Salesforce Connector Connection Issues and API-Only SFDC Users: Troubleshooting Salesforce Connection Issues. Those articles cover cases where the connection itself fails or is blocked. Here, the connection succeeds — it just resolves to the wrong Salesforce user.
Why This Happens
Okta assigns each SSO user an identity to use when authenticating into connected apps, including Salesforce. That assignment is independent of which Salesforce user account someone might expect to be connected. If a person's Okta profile is mapped to Salesforce User B instead of their own Salesforce User A, every OAuth login through Okta will authenticate as User B — regardless of who is physically logging in.
This is a common outcome when Salesforce access was provisioned through Okta by an admin, and the mapping was set up for a different person or role than the one currently signing in.
How to Fix It
This is corrected on the Okta side, by your Salesforce/Okta administrator — HG Insights and the Salesforce connected app have no visibility into or control over this mapping.
- In Okta, locate the Salesforce application assignment for the affected user.
- Confirm which Salesforce account that assignment currently maps to.
- Update the assignment so the Okta user maps to their own correct Salesforce account.
- Have the user re-authenticate through Okta and confirm the Salesforce connection now reflects the correct identity.