The HCP sees one seamless portal. The data walks a permission chain. Part 1 of this series argued that the HCP portal is no longer a website project but an orchestration project – one surface of the same profile that drives email, rep visits and events. This is the layer underneath: identity and consent. Because in pharma, personalization isn’t a feature you switch on. It’s a chain of conditions, and every link is checkable.
What follows is the same journey twice: as the physician experiences it, and as the data has to behave underneath before Adobe Experience Platform is allowed to personalize anything.
Personalization in a pharma portal is not a switch you turn on. Before the portal may show a cardiologist cardiology content, three things must be true, in that order: the physician is verified and the system knows which record is theirs; they have consented, with a timestamp you can show an auditor; and the data that makes the content relevant is labeled, so only the right people and systems can use it. Miss one link and the first internal audit finds specialty data in a campaign filter. The rest of this article is what each link costs and who has to decide it.
What shipped, exactly
- Didomi source in Adobe Experience Platform – GA. Promoted from beta to general availability in the August 2026 release (release date August 18, 2026). It streams consent and preference events from the consent platform into Experience Platform via webhook, in real time – not as a nightly file.
- Object-level access control for datasets – new in the same release. Access labels, until now applied to schema fields, can be applied to entire datasets. Only users whose roles carry the required label can read or write the data.
- Attribute-based access control, unchanged but decisive: labeled fields are hidden from users without the label and cannot be used in segment definitions. The default policy denies access to labeled fields and audiences across all sandboxes.
- Identity namespaces are permanent. Adobe’s documentation is explicit: once a namespace is created it cannot be deleted, and its identity symbol and type cannot be changed. Namespace priority determines which identity becomes primary for experience events – and device or cookie namespaces cannot be ranked above person namespaces.
- On the Salesforce side: Agentforce Life Sciences names the Web Visit Console as the unified view for medical inquiries; Spring ’26 brought visits into the Service Console alongside accounts, cases and medical inquiries. And the profile layer in between is now called Data 360 – the renamed Data Cloud.
Five steps, two layers
Reading the diagram left to right, step by step:
- Arrives. The HCP comes from a congress QR code or a newsletter link, browsing anonymously. Underneath: a device-level ECID from the Web SDK – one identity, no identity graph yet. Behavioral events at most, and only where cookie consent allows them. No Rx content, no personalization. The portal is two experiences, split at login.
- Verifies. One login, DocCheck-style HCP verification. Underneath: the verified ID lands in its own identity namespace and is linked to the profile. That mapping decision – which namespace, which priority, which merge rules – outlives every campaign built on top of it.
- Consents. The HCP chooses channels and purposes once, not per page. Underneath: the consent platform streams purposes and timestamps into the profile through the Didomi source. The timestamp is what the auditor asks for.
- Gets relevance. Specialty-relevant content, in-browser messages, no repeats. Underneath, the step most projects skip: specialty and prescribing-adjacent fields carry access labels. The web team cannot build on attributes it cannot see.
- Asks and is followed up. A medical question in the portal; the rep knows about it before the next visit. Underneath: the inquiry is routed, not marketed – it goes to the Life Sciences org as a transactional record. Portal signals reach the rep’s briefing only if the Data 360 bridge between the orgs is built.
The architecture behind it
Link 1: identity, and the decision you cannot take back
Everything else hangs on identity, because the portal carries two of them and has to join them at the door.
- Before login the profile is a Web SDK ECID – Adobe’s cookie-level identifier, a standard namespace that exists in every organization.
- At verification the portal writes the verified HCP identifier into a namespace of its own.
- The irreversible part: a custom namespace, once created, cannot be deleted and cannot change its type or symbol.
Whether the verified ID is a person namespace or something weaker matters, because namespace priority decides which identity becomes the primary identity of experience events, and Adobe will not let a device or cookie namespace outrank a person namespace. Changing it later means rebuilding the graph relationships that consent and history depend on – which is why this decision belongs in the architecture review, not in the sprint where the login page is built.
Link 2: consent, as a stream instead of a nightly file
The mechanics are now simple: the Didomi source is a webhook. When a user gives or withdraws consent, Didomi sends an HTTP POST with the event payload to Experience Platform. Three things have to exist on your side:
- An XDM schema with at least one identity field and the Profile toggle enabled.
- A dataset to land the events.
- A decision on which identity the consent is written against – the ECID or the verified namespace.
What arrives is the purpose and the timestamp, per identity, as a stream. That closes the gap the nightly file always left open – the hours in which the profile still said “yes” after the HCP had said “no”. The third point is not cosmetic: it decides whether pre-login cookie consent and post-login marketing consent land on the same profile.
// One webhook event = one purpose change, per identity, with the timestamp the auditor asks for{ "_id": "evt-8f3a-…", "timestamp": "2026-09-03T14:12:08Z", "identityMap": { "HCP_ID": [{ "id": "de-4711-…", "primary": true }], // verified namespace – the profile this consent hangs on "ECID": [{ "id": "6155…" }] // pre-login cookie identity, linked at verification }, "consents": { "marketing": { "email": { "val": "y" }, "sms": { "val": "n" } }, "personalize": { "content": { "val": "y" } }, "metadata": { "time": "2026-09-03T14:12:08Z" } }}Structure follows the XDM Consents and Preferences field group (consents.marketing.*.val, consents.metadata.time); namespace and values are placeholders. Whether HCP_ID or ECID is primary is the identity decision from the previous paragraph – it determines which profile the auditor finds this record on.
Six months after go-live you need the verified HCP identifier in a different namespace type. What does Experience Platform let you do?
A custom namespace, once created, cannot be deleted, and neither its type nor its symbol can be changed. The only route is a new namespace – and with it every identity-graph relationship that consent, history and audience membership are built on.
The namespace is chosen in the sprint that builds the login page, by whoever is closest to the login page. It is the one decision in this chain with no undo, so it belongs in the architecture review instead – with the person who will have to explain the consent record two years from now.
Link 3: labels, and what makes the chain auditable
Attribute-based access control is the piece that makes the chain auditable, and it works in four parts:
- Labels on schema fields – and, since August, on whole datasets.
- Matching labels on roles.
- A policy that links the two.
- The effect: users without the label do not see the field in schema, dataset or profile views, and cannot use it in Segment Builder.
For an HCP portal that means the specialty and prescribing-adjacent fields carry a label the web team’s role does not have. They can personalize on what they are allowed to see. Whether an audience built from labeled fields is itself labeled is a deliberate governance decision – Adobe’s default policy denies access to labeled audiences as well – and it needs to be written down, because it is the first thing an internal audit will ask about.
Link 4: the medical inquiry, which leaves Adobe
The last link is the one that leaves Adobe. The medical inquiry is not a marketing event; it is a transactional record that belongs in the Life Sciences org, where Salesforce has put visits, cases and medical inquiries side by side in the Service Console and describes the Web Visit Console as the unified view for inquiries. Nothing in the marketing profile should decide how that inquiry is handled. The reverse direction – the HCP who read the dosing update showing up in the rep’s briefing – only exists if the Data 360 bridge between the marketing profile and the Life Sciences org is designed, with its own consent check. That bridge is architecture work, not a checkbox.
- The verified HCP namespace is chosen and signed off in the architecture review, not in the login sprint – because it cannot be deleted or retyped afterwards.
- Consent arrives as a stream, and everyone knows which identity it is written against.
- Specialty and prescribing-adjacent fields carry a label the web team’s role does not hold.
- Whether audiences built from labeled fields are themselves labeled is written down, not discovered during the audit.
- The medical inquiry creates a record in the Life Sciences org, and the bridge back to the rep has its own consent check.
The fine print
- Namespaces are forever. No deletion, no type change after creation. Prototype in a development sandbox and name for the long term.
- Namespace priority governs experience events, not profile records. Profile records keep the primary identity defined in their schema. Plan both paths.
- Didomi source prerequisites: region-specific IP allowlisting, View and Manage Sources permissions, Adobe API credentials for the webhook, a Profile-enabled schema with an identity field. All of it sits on the critical path before the first consent event lands.
- Dataset labels restrict, they do not classify. A label on the dataset controls who can read or write it; the data-usage labels that drive marketing policies are a separate governance layer. Both need an owner.
- Web Visit in Salesforce terms is the remote-visit surface for reps and MSLs inside the Life Sciences org, now integrated in the Service Console; the inquiry queue lives next to it as medical inquiry records. Confirm with your Salesforce contact how the portal form maps to those records before you promise the medical team a single queue.
- Data 360 is the new name for Data Cloud. Licensing and org design behind the bridge did not get simpler by renaming.
Questions for the portal steering call
- Which namespace holds the verified HCP identity, what is its priority, and who signed that off as a permanent decision?
- Is consent written against the cookie identity, the verified identity, or both – and does the pre-login opt-in survive the login?
- Can the auditor get a consent timestamp per purpose and identity from the profile, without asking IT?
- Which fields carry access labels, which role does the web team have, and is the audience built from labeled fields labeled itself?
- Where does the medical inquiry live, and which system is not allowed to see it?
- Is the bridge to the Life Sciences org designed, budgeted and consent-checked – or is it a line in a slide?
The uncomfortable truth in every portal pitch: the experience layer is the fast part. The permission chain is the project. Get the identity mapping wrong and every consent record hangs on the wrong profile. Skip the labels and the first internal audit finds specialty data in a campaign filter. Personalization isn’t a switch. It’s the chain: verified → consented → labeled.
Part 1 of this series – the architecture: HCP portal, part 1 – the portal is no longer a website project. It is an orchestration project. Also on regulated data in Experience Platform: Meta blocks regulated-data audiences – and AEP now enforces it automatically.
Frequently asked questions
What has to be true before a pharma portal may personalize?
Three things, in that order. The physician is verified and the system knows which record is theirs. They have consented, with a timestamp that can be shown to an auditor. And the data that makes the content relevant is labelled, so only the right people and systems can use it. Verified, consented, labelled – miss one link and the first internal audit finds specialty data in a campaign filter.
Why is an identity namespace an irreversible decision?
Because Adobe’s documentation is explicit: once a namespace is created it cannot be deleted, and its identity symbol and type cannot be changed. Namespace priority determines which identity becomes primary for experience events, and device or cookie namespaces cannot be ranked above person namespaces. Changing it later means rebuilding the graph relationships that consent and history depend on, which is why it belongs in the architecture review rather than the sprint that builds the login page.
How does the Didomi source stream consent into Experience Platform?
As a webhook, promoted from beta to general availability in the August 2026 release on 18 August. When a user gives or withdraws consent, Didomi sends an HTTP POST with the event payload to Experience Platform. You provide a Profile-enabled XDM schema with at least one identity field plus a dataset to land the events. What arrives is the purpose and the timestamp per identity, as a stream rather than a nightly file – which closes the hours in which a profile still said yes after the physician had said no.
What does object-level access control add to attribute-based access control?
Access labels, until now applied to schema fields, can now be applied to entire datasets, so only users whose roles carry the required label can read or write the data. Labelled fields stay hidden from users without the label and cannot be used in segment definitions, and the default policy denies access to labelled fields and audiences across all sandboxes. Whether an audience built from labelled fields is itself labelled is a deliberate governance decision that needs writing down.
The permission chain is where these builds quietly go wrong, and it rarely shows up in UAT. If you want someone to walk yours before go-live, that is the work I do – pharma, medical, finance.
Get in touch →Sources: Adobe Experience Platform release notes, August 2026 · Didomi source overview · Attribute-based access control – end-to-end guide · Identity namespace overview · Namespace priority · Agentforce Life Sciences newsletter, June 2026 · Salesforce Spring ’26 – Manage Visits from the Service Console · 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.; Didomi is a trademark of Didomi SAS; DocCheck is a trademark of DocCheck AG. This is an independent analysis; no partnership with or endorsement by any of these companies. First published as part of my LinkedIn series, September 2026.
