Hi Salesforce Community,
I’m looking for guidance on the right approach for integrating an external web portal with Salesforce, particularly around user authentication, identity mapping, and opening Salesforce record actions in the correct user context.
1. Business Scenario
We have an external web portal called Advisor Portal, where advisors log in using their portal credentials. After logging in, an advisor selects a client and views the client’s details.
On the client details page, the advisor should be able to perform Salesforce activities through actions such as:
- New Task
- New Note
- Log a Call
- New Event
- Send Email
When the advisor clicks one of these actions, the corresponding Salesforce page should open with the selected client’s Account or relevant record automatically populated. The advisor should not have to search for the client again in Salesforce.
2. Expected Behaviour
For example:
- An advisor logs in to the Advisor Portal using their existing portal credentials.
- The advisor searches for and opens a particular client.
- The advisor clicks New Task.
- Salesforce opens the New Task page with the relevant client record automatically populated in the Related To field.
- The advisor enters the task details and saves the record.
- The task is saved in Salesforce and associated with the correct client.
- The activity should be attributed to the appropriate Salesforce user, based on the required business and security rules.
The same principle should apply to Notes, Calls, Events, and Emails, with the appropriate Salesforce page and record context for each action.
3. Main Technical Challenge
The advisor is authenticated in the external portal, but may not already have an authenticated Salesforce browser session.
We need to understand how to securely identify the logged-in portal advisor, map that identity to the corresponding Salesforce User, and open Salesforce under the correct identity without unnecessarily requiring the advisor to log in again.
We also need to distinguish between obtaining an OAuth access token for Salesforce API calls and establishing a browser session for opening Salesforce Lightning pages. We understand these may require different mechanisms.
4. Approaches We Are Exploring
We would appreciate guidance on whether any of the following approaches would be suitable:
- Single Sign-On (SSO) and Federation: Can SSO be used to authenticate the advisor in Salesforce based on their existing portal or identity-provider session?
- OAuth 2.0 Token Exchange: Can the external advisor’s identity be exchanged for a Salesforce access token representing the mapped Salesforce user?
- JWT Bearer Flow: Would this be appropriate for server-to-server authentication, or would it be unsuitable if Salesforce needs to recognise each individual advisor?
- Salesforce Lightning Deep Links: Can we open standard Salesforce New Task, New Event, Log a Call, Note, and Email pages with the appropriate client record prepopulated?
- Apex REST or Middleware: Would a Salesforce Apex REST endpoint or an integration layer be needed to resolve the client and user mapping securely?
We would also like to understand whether a combination of SSO for the browser session and OAuth for backend API access is appropriate.
5. Questions for the Community
- What architecture would you recommend for this portal-to-Salesforce integration?
- How should we map the authenticated portal advisor to the correct Salesforce User?
- What Salesforce configurations are required, such as External Client Apps, OAuth settings, certificates, identity-provider configuration, or user mapping?
- How can we open Salesforce Lightning pages with the correct client record prepopulated?
- How can we ensure activities are recorded under the correct Salesforce user and respect that user’s permissions?
- Is it possible to achieve this without asking every advisor to log in to Salesforce separately?
- Are there any limitations with deep links, browser sessions, OAuth Token Exchange, or JWT Bearer Flow that we should consider?
I’m a Salesforce developer and would appreciate a practical explanation of the end-to-end authentication flow, required prerequisites, and recommended implementation approach.
If anyone has implemented a similar external portal integration, shared a reference architecture, or has relevant documentation or examples, I would be grateful for your guidance.
Thank you!
#Salesforce Developer #Integration
For this pattern I'd use SAML SSO as the backbone, not token exchange.
1. Identity: make the portal's IdP (or your corporate IdP, if both sit behind it) the SAML Identity Provider for Salesforce, with My Domain login enabled. Map each advisor using the Federation ID on their Salesforce User record, and send that same value in the SAML assertion. Each advisor still needs their own Salesforce user and license.
2. Landing on a prefilled page: build the Lightning URL in the portal, for example /lightning/o/Task/new?defaultFieldValues=WhatId=<AccountId>, and pass it as the RelayState (or startURL) of an IdP-initiated SSO. If the advisor has no session, the SSO sets one up silently and they land on the prefilled form. If they already have a session, the deep link just opens.
3. Attribution and permissions: because the record is created in the advisor's own browser session, ownership, sharing and field-level security all apply automatically. That's the main reason to avoid creating activities through an integration user.
4. JWT bearer and token exchange are for API calls made on a user's behalf from your server. They don't give you a browser session, so they suit background sync, not opening Lightning pages.
Common pitfall: Federation IDs drifting out of sync when users are created. Automate user provisioning (SCIM or JIT provisioning) from day one.
