The HCP portal is no longer a website project. It’s an orchestration project. Most pharma portals are still built like microsites: an agency, a CMS, a login, a PDF library. Then they sit there, disconnected from every other channel, and the medical inquiry form sends an email to a shared inbox.
What shipped across Adobe Experience Platform and Journey Optimizer and Agentforce Life Sciences in the past months changes what a portal can be. Not because any single feature is spectacular, but because the pieces now line up: the portal becomes one surface of the same profile that drives email, rep visits and events. This is part 1 of two – the architecture. Part 2 covers the layer underneath: identity and consent.
The portal you are buying is not a website. It is a front door to the same customer profile your email, your reps and your events already use. Three things to insist on in the pitch: content comes from the one approved source and is never re-approved in the portal; the medical inquiry lands in the medical team’s system, not in an inbox; and whatever the physician does in the portal reaches the rep only if someone builds and pays for that bridge – ask who. The rest of this article is how those three get built.
What shipped, exactly
- Journey Optimizer web channel – in-browser experiences on your own web properties, personalized per profile, authored visually. Prerequisite that decides the architecture: it needs the Experience Platform Web SDK on the page (client-side), or the hybrid setup where the Edge Network Server API requests personalization server-side and the Web SDK renders it. Adobe is explicit that a server-side-only implementation “is not currently supported with the Web channel” – for that, use the code-based experience channel.
- Inbound experience simulation in Action Campaigns – announced by Adobe as coming soon: simulate inbound channel actions before going live, with simulated users and a preview of the rendered experience including a generated URL and QR code, to validate rules, decisioning and rendering end-to-end. Private beta, limited set of organizations, subject to change.
- Agentforce Life Sciences, Spring ’26: presentations can be shared with HCPs as unique email links instead of attachments – the HCP views the content in a dedicated portal, availability and link expiry are managed centrally, and page-level engagement data flows back. Visits, cases and medical inquiries now sit side by side in the Service Console; Salesforce’s Life Sciences newsletter names the Web Visit Console as the unified view for medical inquiries.
- The profile layer between the two: Salesforce Data Cloud is now called Data 360. Whether portal signals reach the rep is a question of whether that bridge is built, not of which name it carries.
One portal, two brands, five decisions
Take a DACH mid-size pharma company, two brands, one authenticated HCP portal. Five decisions shape the architecture:
- Login and consent first. HCP verification at the door; consent streamed from the consent platform into the profile. The anonymous visitor sees no Rx content and gets no personalization. The portal is two experiences, split at login.
- Content stays MLR-governed. Approved assets come from the content vault; the portal renders them, it never re-approves them. The same approved version feeds the rep’s presentation link – so the tracked link in the follow-up email and the portal page show the same thing.
- The experience layer is a channel, not a CMS feature. Journey Optimizer’s web channel puts personalized in-browser experiences on the logged-in portal – per profile, governed by the same journey and campaign logic as email. Client-side Web SDK or hybrid; a purely server-side portal goes the code-based route.
- The medical inquiry stops being an email. The portal form lands as a record in the Life Sciences org, in the Service Console next to visits and cases, with the audit trail where the inquiry lives – not in a shared inbox.
- The loop closes – if the bridge is built. The HCP who read the dosing update on Tuesday shows up in the rep’s briefing on Thursday, provided portal signals cross from the marketing profile into the Life Sciences org. That is architecture work, not a checkbox.
The architecture behind it
Decision 1: how the portal is rendered
This is the decision that shapes every other one, and it belongs on the table before the agency writes the first template: it determines what the front end has to load and where the verified identity is passed. Journey Optimizer’s web channel modifies pages through the Experience Platform Web SDK, which leaves three routes.
- Fully client-side. The Web SDK requests the personalization decision and renders it in the browser. Quickest to stand up, and the route most likely to flicker between the generic and the personalized version of a page.
- Hybrid – usually the right answer for a regulated portal. The portal’s server calls the Edge Network Server API for the decision and hands the response to the Web SDK to render. The server knows who is logged in and passes that identity with the request, and the rendered page does not flicker.
- Server-rendered with no Web SDK on the page at all. The web channel is not available – Adobe states plainly that a server-side-only implementation is not supported for it. The code-based experience channel delivers the same decisioning as content fragments your server injects.
// 1. Server-side: request the personalization decision for the logged-in HCPPOST https://edge.adobedc.net/ee/v2/interact?dataStreamId={DATASTREAM_ID}{ "events": [{ "xdm": { "identityMap": { "HCP_ID": [{ "id": "de-4711-…", "primary": true }] }, "web": { "webPageDetails": { "URL": "https://portal.example-pharma.de/dashboard" } }, "eventType": "web.webpagedetails.pageViews" }, "query": { "personalization": { "surfaces": ["web://portal.example-pharma.de/dashboard"] } } }]}// 2. Client-side: hand the decisions from the response to the Web SDK, which renders themalloy("applyPropositions", { propositions: response.handle/* personalization:decisions */ });Shape of the Edge Network Server API interact call and the Web SDK applyPropositions command from Adobe’s hybrid-personalization documentation; namespace, surface and field values are placeholders. The verified identity travels with the server-side request – that is the point of the hybrid setup.
Your portal is server-rendered and the front end loads no Web SDK. Which route to personalization is open to you?
The web channel modifies pages through the Web SDK, and Adobe is explicit that a server-side-only implementation “is not currently supported with the Web channel”. For that case the documented path is the code-based experience channel.
This is the one decision that is expensive to reverse. It sets what the front end loads, where identity is passed, and which team owns rendering – which is why it belongs in the kick-off and not in the first sprint review.
Decision 2: where approved content lives
Content governance should not be a portal decision at all. Approved assets have one home – the MLR-governed content repository – and every surface references them. The portal renders what is approved; it does not carry a second copy. On the Salesforce side, the Spring ’26 link-sharing feature makes that concrete:
- The rep sends a presentation as a unique link from a pre-approved email template, instead of an attachment.
- The HCP opens it in a dedicated portal; availability and link expiry are managed centrally.
- Page-level engagement data – pages viewed, time per page, navigation path – flows back.
The architectural consequence: the portal and the rep’s link have to resolve to the same approved version. That means the content pipeline into the portal is fed from the same source as the field tooling – not from the agency’s CMS.
Decision 3: where the medical inquiry lands
A medical inquiry is a transactional record with an audit trail, not a marketing event. Salesforce has put visits, cases and medical inquiries side by side in the Service Console in the Life Sciences org; the portal form should create that record directly, so the medical team works one queue with the history attached. Nothing in the marketing profile decides how the inquiry is handled.
The reverse direction – portal engagement enriching the rep’s briefing – is the Data 360 bridge between the marketing profile and the Life Sciences org, and it comes with its own consent check. Design it as a deliberate integration with a defined set of signals, not as a general profile sync.
Decision 4: how you prove it before go-live
Regulated portal teams need to prove, before go-live, that the anonymous visitor cannot see Rx content and the logged-in specialist sees the right variant. Adobe’s announced inbound simulation for Action Campaigns – simulated users, a generated URL and QR code, end-to-end validation of rules and rendering – is exactly that proof. It is private beta and subject to change, so ask your Adobe contact before you plan UAT around it; until then, the test path is real test profiles in a development sandbox.
- The rendering mode is decided and written down before the first template exists – and if the portal is server-side only, the web channel is off the table.
- Every asset the portal shows resolves to the same approved version the rep’s link resolves to.
- The medical inquiry creates a record in the Life Sciences org, not an email in a shared inbox.
- The path from portal engagement to the rep’s briefing has a named owner and a defined list of signals.
- There is a test that proves an anonymous visitor cannot reach Rx content, and it runs before go-live.
The fine print
- Web channel needs the Web SDK (version 2.16 or above) on the page, client-side or hybrid. Server-side only is not supported – use code-based experiences instead.
- Inbound simulation is not GA. Coming soon, private beta, limited organizations, availability subject to change. Do not put it on a project plan as a dependency.
- Link sharing is a Life Sciences Cloud for Customer Engagement feature – Enterprise or Unlimited edition, Life Sciences Cloud license plus the Customer Engagement add-on and managed package; mobile on iPad only.
- “Web Visit” in Salesforce terms is the rep/MSL remote-visit surface, now integrated in the Service Console; medical inquiries are records next to it. Confirm how your portal form maps to those records before promising the medical team a single queue.
- The bridge is not a product. Data 360 is the renamed Data Cloud; the integration between marketing profile and Life Sciences org is designed, consent-checked and licensed per project.
Questions for the portal kick-off
- Is the portal rendered client-side, hybrid or server-side – and who decided that with the channel architecture in mind?
- Where is the single approved source for content, and does the portal reference it or copy it?
- Does the rep’s shared link and the portal page resolve to the same approved version?
- Where does the medical inquiry record live, and who sees it?
- Which portal signals are allowed to reach the rep’s briefing, under which consent?
- How do you prove, before go-live, that the anonymous visitor sees nothing they shouldn’t?
The part most projects get wrong: none of these pieces is the portal. The portal is just one surface of the same profile – the same consent, the same approved content, the same signals that drive email, rep visits and events. The portal isn’t the destination. It’s one surface of the same profile.
Part 2 of this series – identity and consent, the layer underneath: HCP portal, part 2 – the HCP sees one seamless portal, the data walks a permission chain. Also on Journey Optimizer in regulated stacks: AJO now attaches the documents customers actually open.
Frequently asked questions
How does an HCP portal have to be rendered for the Journey Optimizer web channel?
The web channel modifies pages through the Experience Platform Web SDK, version 2.16 or above – either fully client-side, or in hybrid mode where the portal server calls the Edge Network Server API for the personalization decision and hands the response to the Web SDK to render. A server-side-only implementation is not supported; for that, the code-based experience channel delivers the same decisioning as content fragments the server injects. For a regulated portal, hybrid is usually the right answer: the server knows who is logged in, and the page does not flicker between generic and personalized content.
Where should a medical inquiry from the portal form land?
In the Life Sciences org, as a transactional record next to visits and cases in the Service Console – not in a shared inbox. The inquiry is a record with an audit trail rather than a marketing event, which means nothing in the marketing profile should decide how it is handled.
Does portal engagement automatically reach the sales representative?
No. That path is the Data 360 bridge between the marketing profile and the Life Sciences org, and it exists only if someone designs, consent-checks and licenses it per project. Data 360 is the renamed Data Cloud; the rename did not make the org design behind the bridge any simpler.
Where should approved content live in a portal architecture?
In one place: the MLR-governed content repository. Every surface references it, and the portal renders what is approved rather than carrying a second copy. The practical test is whether the representative’s shared presentation link and the portal page resolve to the same approved version – which they only do if the content pipeline is fed from the same source as the field tooling, not from an agency CMS.
Four decisions, and three of them are expensive to reverse. If your portal project is still in the kick-off phase, this is exactly the point where a second opinion is cheap.
Get in touch →Sources: Adobe Journey Optimizer – web channel prerequisites · Get started with web channel · Get started with code-based experiences · Journey Optimizer release notes – inbound experience simulation (coming soon) · Salesforce Spring ’26 – Share Presentations as Unique Email Links · Salesforce Spring ’26 – Manage Visits from the Service Console · Agentforce Life Sciences newsletter, June 2026 · Salesforce Ben – Data Cloud renamed to Data 360. Adobe, Adobe Experience Platform and Adobe Journey Optimizer are trademarks of Adobe Inc.; Salesforce, Agentforce and Data 360 are trademarks of Salesforce, Inc. This is an independent analysis; no partnership with or endorsement by Adobe or Salesforce. First published as part of my LinkedIn series, August 2026.
