Category: Adobe Experience Cloud

Deep dives on AEP, Real-Time CDP, Journey Optimizer and the Adobe stack.

  • HCP portal, part 2: the HCP sees one seamless portal. The data walks a permission chain

    HCP portal, part 2: the HCP sees one seamless portal. The data walks a permission chain

    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.

    If you read one paragraph · for CMOs and omnichannel leads

    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

    The permission chain under the HCP portalThe same journey in two layers across five steps. Top row, what the HCP experiences: arrives, verifies, consents, gets relevance, asks a question. Bottom row, what the data does: pseudonymous with ECID only, identity mapped, consent streamed, labels gate access, routed rather than marketed. A gate bar below the second row marks three gates — verified, consented, labeled — before personalization is allowed.WHAT THE HCP EXPERIENCESArrivescongress QR code ornewsletter link, anonymousVerifieslogs in once, DocCheck-style verificationConsentschannels and purposes —once, not per pageGets relevancespecialty content andin-browser messagesAsks a questiona medical inquiry — the repknows before the visit0102030405WHAT THE DATA DOESPseudonymousECID only, no Rx contentand no personalizationWEB SDKIdentity mappedverified ID in its ownnamespace on the profileIDENTITY SERVICEConsent streamedpurposes + timestamp asa stream, not a fileDIDOMI SOURCE · GALabels gate accessspecialty fields carrytheir own access labelsABAC · DATASET LABELSRouted, not marketedinquiry to the LS org;signals only if bridgedDATA 360 WIRINGSTARTPERSONALIZATION ALLOWEDverifiedconsentedlabeledPersonalization isn’t a switch. It’s the chain — and every link is checkable by an auditor.
    Same journey, two layers. The gates between the data steps are the permission chain – personalization is allowed only after all three.

    Reading the diagram left to right, step by step:

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.

    Consent event as it lands in the profile · Didomi source, streamed
    // 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.

    Architecture check · Identity

    Six months after go-live you need the verified HCP identifier in a different namespace type. What does Experience Platform let you do?

    Your answer

    What Adobe documents

    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.

    Why it matters

    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.

    Source: Identity namespaces · retrieved 13 Sep 2026

    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.

    Architecture checkpoint · what has to be true
    • 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

    Steering call · questions to settle
    • 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.

    Working on this?

    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.

  • AJO now attaches the documents customers actually open

    AJO now attaches the documents customers actually open

    Adobe Journey Optimizer’s August release quietly solved a problem every bank and insurer knows: the document email. Contract confirmations, policy documents, tax certificates – the emails customers actually open are the ones that never came from the marketing platform. They came from a separate output management system, with a plain template and “no-reply” as the sender.

    The reason was structural. The PDF is generated per recipient, upstream, in the core system. And until now, Journey Optimizer could only attach one static file. Since August 12, that constraint is gone.

    What shipped, exactly

    • Up to five PDF attachments per email in API-triggered campaigns – static and recipient-specific, five in total per message.
    • Recipient-specific files are fetched from Data Landing Zone and attached at send time; each file’s location is passed directly in the API payload.
    • Upstream document generation stays where it is. Journey Optimizer handles delivery only – no migration of the rendering system.
    • Documented use cases: invoices, statements, tickets, contracts, shipping labels – anything that varies per recipient.
    • Base entitlement (from the attachment documentation): 5 MB maximum per file, and 6 messages with a PDF attachment per profile per year. Larger volumes and sizes require the PDF Attachments add-on.
    • Availability date: August 12, 2026.

    What this looks like for a retail bank

    Picture a retail bank with three million customers and 400 branches. A customer signs a consumer loan in the app:

    1. The core system confirms the contract, and output management renders the contract PDF – exactly as it does today.
    2. The bank’s integration layer drops the file into Data Landing Zone and calls the Journey Optimizer API, passing the file location in the payload.
    3. Within seconds the confirmation lands in the inbox – in the same design system as the onboarding emails, with the same tracking every other message carries.
    4. Two days later, the advisor follow-up goes out. From the same release: in Orchestrated Campaigns, the sender can now be the advisor’s own name and reply-to address rather than a corporate no-reply (Limited Availability).
    5. Quiet hours keep that outreach out of the evening; wave sending keeps it out of the call center’s Monday morning.
    6. In Customer Journey Analytics, the contract email, the advisor follow-up and the app push appear as one journey – not three systems, three reports and a spreadsheet to glue them together.

    The architecture behind it

    The design decision worth understanding is where Adobe placed the boundary. Journey Optimizer does not generate the document and does not store it. Data Landing Zone acts as the handover point: your integration layer writes the rendered PDF there, and the API payload carries a pointer to it. At send time, Journey Optimizer fetches the file and attaches it. That keeps the document system – usually the most heavily validated component in a regulated stack – entirely untouched.

    This matters for implementation sequencing. In most banks and insurers, output management sits inside the core banking or policy administration system, under its own change control and its own audit trail. A project that required moving document generation into the marketing platform would have been a multi-year program with a compliance workstream attached. A project that adds a file drop and an API call is an integration task measured in sprints. The delivery layer changes; the system of record does not.

    The second architectural point is the channel restriction, and it reads as deliberate rather than incidental. Personalized attachments work in transactional API-triggered campaigns only – not in journeys, not in orchestrated campaigns. That keeps documents on the transactional path, structurally separated from anything requiring marketing consent. In a GDPR context that separation is not a limitation to work around; it is the boundary you would have drawn yourself during the consent design.

    The fine print

    • Five is the total, not the personalized allowance. Static and recipient-specific files share the same limit of five per email.
    • The entitlement is per profile, per year. Six PDF messages annually is modest for a bank that sends statements monthly – model your volume against the add-on before committing to a use case.
    • The attachment documentation has not caught up. The attachment page was last updated on June 14, 2026 and still describes the static workflow only. Error behavior for a missing or oversized file at send time is not publicly documented – clarify it with Adobe before go-live rather than discovering it in production.
    • Sender personalization is Limited Availability. The advisor-as-sender capability requires Adobe to enable it for your organization.
    • Attachments do not survive content templates. Save a message as a template and the PDF attachment is dropped; it has to be reattached.

    Questions to settle before you scope this

    1. Where does document rendering live today, and who owns the change control around it?
    2. Can your integration layer write to Data Landing Zone, and what is the latency between contract signature and file availability?
    3. What is your realistic annual attachment volume per customer – and does that fit the base entitlement or require the add-on?
    4. What happens if the file is missing or oversized at send time? Get this answer from Adobe in writing.
    5. Which documents belong on the transactional path, and does your consent model already reflect that split?
    6. Who owns the reporting story once document emails appear in Customer Journey Analytics alongside marketing touchpoints?

    Documents are the highest-open touchpoint a bank has. Until now they lived outside the platform where every other touchpoint was measured. The document system does not change – the delivery layer does.

    Also from the August release: quiet hours now cover Orchestrated Campaigns · content simulation renders every variant in one grid.

    Also on Journey Optimizer in pharma: HCP portal, part 1 – the portal is no longer a website project. It is an orchestration project.

    Frequently asked questions

    How many PDF attachments can an Adobe Journey Optimizer email carry?

    Up to five per email in API-triggered campaigns, available since 12 August 2026. Five is the total, not the personalized allowance: static and recipient-specific files share the same limit of five per message.

    Where are recipient-specific PDFs generated and stored?

    Not in Journey Optimizer. Document generation stays upstream where it already sits, and Data Landing Zone acts as the handover point: the integration layer writes the rendered PDF there, the API payload carries a pointer to it, and Journey Optimizer fetches and attaches the file at send time. The system of record – usually the most heavily validated component in a regulated stack – stays untouched.

    What are the entitlement limits for PDF attachments?

    The base entitlement is a maximum of 5 MB per file and six messages with a PDF attachment per profile per year; larger volumes and sizes require the PDF Attachments add-on. Personalized attachments also work in transactional API-triggered campaigns only, not in journeys or orchestrated campaigns, which keeps documents structurally separated from anything requiring marketing consent.

    Working on this?

    Personalised attachments look like a content task and behave like an architecture one – the document has to resolve against a profile that is actually correct. I build those pipelines for teams in regulated industries.

    Get in touch →

    Sources: AJO release notes – August 2026 (Campaigns) · Attach a PDF file to an email · Personalize email sender details · Send using waves. Adobe, Adobe Journey Optimizer and Customer Journey Analytics are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe. First published as part of my LinkedIn series, September 2026.

  • AJO quiet hours now cover everything – and the 2 a.m. text becomes a leadership decision

    AJO quiet hours now cover everything – and the 2 a.m. text becomes a leadership decision

    One corner of Adobe’s marketing platform used to ignore night-time sending rules. On August 18, Adobe closed it. Since then, every 2 a.m. text a bank sends is a decision – not a technical excuse.

    Quiet hours in Journey Optimizer block messages during set time windows – across email, SMS, push and WhatsApp. The feature has been generally available since January 29, 2026. What changed in August: Orchestrated Campaigns, AJO’s batch campaign type and the last exempt send type, now support quiet hours too. One protection now covers campaigns, journeys and batch orchestration alike.

    What shipped, exactly

    • January 29, 2026 – GA: quiet-hours rules in rule sets for email, SMS, push and WhatsApp; queue or discard per rule; preview of the activated rule.
    • August 18, 2026 – Orchestrated Campaigns: the earlier “not supported for Orchestrated campaigns” limitation is gone.
    • Timezone logic: one fixed window for all recipients, or the recipient’s local time from the profile timezone field.

    One night under quiet hours

    Picture a German retail bank, six million customers, quiet hours set to 21:00–08:00. The featured architecture above walks through a single night:

    1. 20:55 – a payment-reminder SMS batch starts; part of it gets out before the window.
    2. 21:00 – the rest is held automatically and waits. The rule says queue, not delete.
    3. Classification – every action has been classified beforehand: marketing, service or security – hold, drop or bypass. This is the human decision in the middle of the diagram.
    4. 03:12 – a card gets flagged; the fraud alert carries no quiet-hours rule and fires immediately.
    5. 08:00 – the held reminders release into the morning.

    The expensive part is step three – and it isn’t software. The platform cannot know which message is marketing noise and which one means “your card just got blocked.” Someone has to classify everything the company sends, across every channel and every team. A CMO who skips that inventory gets the dark side of the switch: fraud alerts held politely until breakfast.

    The architecture behind it

    The setup path in AJO: Journey Optimizer → Business rules → custom rule set (Channel domain – the global rule set can’t hold quiet hours) → Add rule → type Quiet hours. Up to five time periods per rule, weekly or custom dates, optional all-day. Choose queue or discard, activate, then attach the rule set per channel action – in campaigns via the Actions tab, in journeys on the channel action itself.

    Architecturally, quiet hours are opt-in per action: the rule category is read-only “Marketing”, so service and security actions bypass the window by simply not carrying the rule. That is the mechanism that lets the fraud alert through at 03:12 – and the reason the classification inventory is the real project, not the rule setup.

    The fine print

    • A profile with no timezone value is not protected – the rule silently doesn’t apply.
    • Messages queued for more than seven days are discarded.
    • Discard on a journey action means the profile exits the journey entirely.
    • Rule updates take up to 12 hours to reach actions already using the rule – tonight’s window can’t be fixed this afternoon.
    • On high-volume sends, suppression enforcement can lag; quiet-hours exclusions show up in the CJA channel report and the Live report.

    Six questions to settle before switching it on

    1. Who owns the classification list – which sends are marketing, service, security?
    2. Hold or drop per message class – and what does a dropped payment reminder do to the dunning process downstream?
    3. How many profiles carry no timezone value today? That is the share of your base with zero protection.
    4. Fixed window vs. recipient local time – one national market may not need profile timezones; twelve markets do.
    5. Who monitors the queue – which held messages are approaching the 7-day discard?
    6. Does anything downstream assume the message went out the moment the journey passed the action?

    Quiet hours aren’t a politeness setting. They’re a forced decision about which messages matter at 3 a.m. – and that decision belongs to the business, not the platform.

    Also from AJO’s August release: the journey-level holdout – the feature that sends nothing and proves everything.

    Frequently asked questions

    Which send types do quiet hours cover in Journey Optimizer?

    Since 18 August 2026, Orchestrated Campaigns as well – the last exempt send type. Quiet hours have been generally available since 29 January 2026 for email, SMS, push and WhatsApp, so one protection now covers campaigns, journeys and batch orchestration alike.

    Do quiet hours apply to every profile?

    No. A profile with no time zone value is not protected and the rule silently does not apply. Quiet hours are also opt-in per action: the rule category is read-only Marketing, so service and security actions bypass the window simply by not carrying the rule. That is the mechanism that lets a fraud alert through at three in the morning.

    What happens to messages that quiet hours hold back?

    Per rule they are either queued or discarded. Messages queued for more than seven days are discarded. A discard on a journey action means the profile exits the journey entirely. And rule updates take up to 12 hours to reach actions already using the rule, so tonight’s window cannot be fixed this afternoon.

    Working on this?

    Quiet hours are easy to switch on and easy to get wrong once several journeys touch the same profile. If you run more than a handful, it is worth checking what actually collides.

    Get in touch →

    Sources: Adobe Journey Optimizer release notes (August 2026 section and 2026 archive) and “Set quiet hours” on Adobe Experience League – fetched August 31, 2026. Adobe, Adobe Journey Optimizer and Real-Time CDP are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe.

  • HCP portal, part 1: the portal is no longer a website project. It is an orchestration project

    HCP portal, part 1: the portal is no longer a website project. It is an orchestration project

    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.

    If you read one paragraph · for CMOs and omnichannel leads

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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

    HCP portal as one surface of the same profileThree zones. Left: Adobe Experience Platform with consent platform, Real-Time Customer Profile and Journey Optimizer. Centre: the HCP portal splits at login into an anonymous state without personalization and a verified HCP state. Right: the Agentforce Life Sciences org with service console and rep presentation link. Below the portal, one MLR-governed content source is referenced by both the portal and the rep link. A dashed bridge across the top marks the Data 360 connection that exists only if it is built.ADOBE AEP · JOURNEY OPTIMIZERHCP PORTAL · ONE SURFACEAGENTFORCE LIFE SCIENCES ORGConsent platformpurposes + timestamps, streamedDIDOMI SOURCE · GAReal-Time Customer Profileverified HCP identity, consent,behaviourONE PROFILE · ALL CHANNELSJourney Optimizerweb channel — Web SDK or hybrid,code-basedEXPERIENCE LAYERAnonymouscongress QR, newsletter link —no Rx content, no personalizationECID ONLYVerified HCPspecialty-relevant content,in-browser messages, inquiry formVERIFIED · CONSENTED · LABELEDService Consolevisits · cases · medical inquiriesone queue for the medical teamTRANSACTIONAL · AUDIT TRAILRep · presentation linkunique link, expiry, page-levelengagementSEND AS LINK · SPRING ’26MLR-governed content sourceone approved version — referenced,never copiedVAULT / APPROVED ASSETSpersonalizeinquiryrenderssame versionsplit at loginData 360 bridge — only if built, consent-checkedIN SCOPE OF THE PORTAL PROJECTEXISTS ONLY IF DESIGNED AND BUILTPRE-LOGIN STATE
    One portal, one profile: the pieces, and the two links that only exist if someone designs them – the content pipeline and the bridge to the Life Sciences org.

    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.
    Hybrid setup · portal server asks the Edge Network, Web SDK renders
    // 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.

    Architecture check · Rendering

    Your portal is server-rendered and the front end loads no Web SDK. Which route to personalization is open to you?

    Your answer

    What Adobe documents

    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.

    Why it matters

    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.

    Source: Get started with the web channel · retrieved 13 Sep 2026

    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.

    Architecture checkpoint · what has to be true
    • 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

    Kick-off checklist · questions to settle
    • 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.

    Working on this?

    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.

  • AJO journey-level holdout: the feature that sends nothing – and proves everything

    AJO journey-level holdout: the feature that sends nothing – and proves everything

    This week, Adobe ships a feature that does… nothing. It sends no emails. No SMS. Nothing at all – to a slice of your customers. On purpose. And it might be the most valuable thing in the entire August release.

    The feature is called journey-level holdout, part of Adobe Journey Optimizer‘s August 18 update – Limited Availability for now, meaning your Adobe contact has to enable it.

    The idea, borrowed from medicine

    New drugs aren’t approved because patients “felt reached.” They’re tested against a group that gets no treatment – the difference between the groups is the proof. Marketing almost never does this: everyone gets the campaign, so there is nothing to compare against. Which means “our journeys drove €2M this quarter” is usually a belief, not a measurement.

    What shipped, exactly

    • Journey-level holdout (Aug 18–19, Limited Availability): set a percentage directly on a journey; that share of the target audience is excluded from entering the journey and receives no communication from it.
    • Measurement: lift is read in Customer Journey Analytics by comparing holdout profiles against active profiles.

    The architecture behind it

    The holdout is configured in journey properties – an entry-level exclusion, not a message variant. That is exactly why A/B tests never answered this question: a content experiment compares message A against message B, and both groups get something. It tells you which message wins – never whether the journey should exist at all. The journey-level holdout is the missing control group.

    Why this matters for the budget round

    When a CFO asks what the marketing platform contributed this year, “we sent 40 million messages” is activity. “Customers in journeys spent 12% more than identical customers who weren’t in them” is an answer. The CMOs who deliberately hold customers back will win the 2027 budget rounds; the ones reporting opens and clicks will keep explaining themselves.

    Questions to settle

    1. Which journeys get a holdout first – the expensive ones, the contested ones, or the ones you’re proudest of?
    2. What holdout share can you defend – 5% is statistically thin on small audiences, 10% hurts on revenue journeys.
    3. Is CJA set up to compare holdout vs. active profiles on the metrics the CFO actually cares about?
    4. Who is allowed to see the result – and what happens if a flagship journey shows no lift?

    Would you dare to hold back 10% of your best customers to prove your marketing works?

    Also in AJO’s August timeframe: quiet hours now cover Orchestrated Campaigns · content simulation renders every variant in one grid.

    Frequently asked questions

    What is a journey-level holdout in Adobe Journey Optimizer?

    A percentage set directly on a journey. That share of the target audience is excluded from entering the journey and receives no communication from it. The feature shipped on 18 and 19 August 2026 in Limited Availability, which means an Adobe contact has to enable it.

    How is a holdout different from an A/B test?

    An A/B test compares message A against message B, and both groups receive something. It tells you which message performs better, never whether the journey should exist at all. The journey-level holdout is configured in journey properties as an entry-level exclusion, which makes it the control group an A/B test cannot provide.

    Where is the lift from a holdout measured?

    In Customer Journey Analytics, by comparing holdout profiles against active profiles – not in journey reporting. That means the measurement has to be set up on the metrics the business actually cares about before the first holdout runs.

    Working on this?

    A holdout only proves something if the split happens where you think it does. If you want your measurement set up so the number survives a stakeholder question, that is work I do.

    Get in touch →

    Sources: Adobe Journey Optimizer release notes and pre-release notes on Adobe Experience League, August 2026. Adobe, Adobe Journey Optimizer and Customer Journey Analytics are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe. First published as part of my LinkedIn series, August 2026.

  • AJO content simulation: the version nobody previewed now shows up in a grid

    AJO content simulation: the version nobody previewed now shows up in a grid

    The most embarrassing email a bank can send starts with: “Hello ${firstName},”. Someone wrote it. Someone approved it. Someone previewed it – just not this version.

    Adobe’s August release for Journey Optimizer (AJO) targets exactly this blind spot. Since August 11, content simulation renders every variant of a message side by side in one grid – now generally available for everyone.

    What shipped, exactly

    • Content simulation is GA since August 11, 2026, as part of AJO’s August release.
    • Sample profiles come from a file – CSV, JSON or JSONLINES – with up to 30 variants per run. No test profiles in the production customer database.
    • Or the built-in AI builds the matrix for you: it reads your personalization fields and conditional branches and derives the variants – capped at 40.
    • Scope: email, SMS, push, all inbound channels (web, code-based experiences, in-app, content cards) and orchestrated campaigns.
    • The grid replaces the sequential preview flow – one consolidated action bar, all variants scrollable side by side.

    The QA fixture pattern

    Here is how this plays out for a banking team that treats the feature seriously:

    1. Build a sample file that mirrors the profile structure – and treat it as a test fixture: version it in the same repo as your content workflows.
    2. Fill it with ugly cases: missing first names, 40-character double surnames, a locale your fallback logic has never met.
    3. Load the file into content simulation and render the full grid.
    4. Review side by side. The variant nobody rendered is the one review never saw – in pharma, that variant is MLR-approved content that no reviewer ever laid eyes on in its rendered form.

    The architecture behind it

    The sample payload mirrors the Experience Platform profile structure (profile.attributes.person.name and friends), so anything your personalization logic can reference can be mocked. The decisive design choice sits underneath: nothing is written to the AEP profile store. For regulated teams that is the actual headline – no synthetic customers in production, no consent records to fake, nothing for internal audit to flag. Until now, realistic variant testing usually meant seeding fake profiles into the production database, and in banking that is an audit finding waiting to happen.

    The AI-assisted path goes one step further: instead of hand-maintaining the matrix, AJO parses the personalization tokens and conditional-content branches in the message and generates the variant set itself, up to 40 combinations. That matters because the branches nobody remembers are exactly where broken fallbacks live.

    The fine print

    • Event data from inside a journey cannot be mocked here. Event-triggered personalization still needs testing in journey context.
    • This is not journey simulation. That (separate) AJO feature tests flow and timing – content simulation tests what your customer actually reads.
    • The caps are real: 30 variants via file or manual entry, 40 via AI generation. Messages with more combinatorics need prioritized sampling.
    • The sample file is your responsibility. Adobe gives you the renderer – the discipline of versioning and maintaining the fixture is on your team.

    Questions to settle before your next campaign

    1. How many variants of your last campaign did a human actually see – honestly?
    2. Who owns the sample file, and is it versioned like the test fixture it is?
    3. Which conditional branches carry MLR- or compliance-approved content that has never been rendered end to end?
    4. Where does event-triggered personalization get tested, given it cannot be mocked here?
    5. Does variant QA time show up anywhere in your content-velocity metrics – or is it invisible work?

    Personalization programs rarely stall on ideas. They stall on QA. When a CMO asks why one campaign takes three weeks, the honest answer is often: someone clicks through 30 previews by hand. That someone just got a grid.

    Also from AJO’s August release: the journey-level holdout – the feature that sends nothing and proves everything.

    Frequently asked questions

    What does content simulation in Adobe Journey Optimizer do?

    It renders every variant of a message side by side in one grid, generally available since 11 August 2026. Sample profiles come from a file – CSV, JSON or JSONLINES – with up to 30 variants per run, or the built-in AI reads the personalization fields and conditional branches and derives the variant set itself, capped at 40. It covers email, SMS, push, all inbound channels and orchestrated campaigns.

    Does content simulation write test profiles into the production database?

    No, and that is the decisive design choice. Nothing is written to the Experience Platform profile store. The sample payload mirrors the profile structure, so anything the personalization logic can reference can be mocked – without seeding synthetic customers into production, which is exactly what made realistic variant testing an audit finding waiting to happen in regulated teams.

    What can content simulation not test?

    Event data from inside a journey cannot be mocked here, so event-triggered personalization still needs testing in journey context. It is also not journey simulation, which tests flow and timing; content simulation tests what the customer actually reads. The caps are real: 30 variants via file or manual entry, 40 via AI generation.

    Working on this?

    Simulation is only as good as the profile you simulate against. Getting representative test profiles into a sandbox is unglamorous, and it is where most preview processes quietly fall apart.

    Get in touch →

    Sources: AJO release notes (August 2026) · Simulate content variations documentation (updated Aug 11, 2026). Adobe, Adobe Journey Optimizer and Adobe Experience Platform are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe. First published as part of my LinkedIn series, August 2026.

  • AEM Forms brings regulated correspondence into the cloud – and the account statement becomes a CX channel

    AEM Forms brings regulated correspondence into the cloud – and the account statement becomes a CX channel

    Unpopular opinion: your bank’s best marketing channel isn’t email. It’s not the website either. It’s the account statement. Marketing emails get opened by maybe one in five customers – statements, policy letters and benefit notices are read by nearly everyone, line by line. These documents shape how trustworthy a company feels. And in most banks and insurers they are built far away from the marketing team: on a Windows-only desktop tool, owned by IT or operations, last redesigned years ago. That just changed.

    What shipped, exactly

    • June 2026 release (2026.6.0, June 25), now GA: Adobe moved Interactive Communications into AEM Forms as a Cloud Service. Customer correspondence – statements, bills, policy documents, welcome kits – is now authored in the browser, on the same cloud platform as website and campaigns.
    • Previously: Interactive Communications existed in AEM 6.5 Forms, but authoring required the Windows-only Desktop Designer. The Cloud Service editor runs fully in the browser, including XDP file editing.

    The architecture behind it

    Data binding runs via Form Data Models (FDM): a visual mapping of document components to the data source, so statements render per customer. Template locking is the governance control – layout and fragments like headers, footers and legal disclaimers are locked at template level, and authors can only edit what governance allows. That is MRM/compliance control built into the authoring layer rather than bolted on as a review step.

    Around it: versioning, annotation-based review and side-by-side PDF version compare give correspondence changes an audit trail. And the Associate UI provides a runtime interface on publish instances where front-line staff enter data and generate personalized documents in real time – no developer needed.

    Why this matters for the operating model

    When a CMO maps customer touchpoints, correspondence is usually missing from the slide. When a COO budgets document operations, marketing is never in the room. This release puts both at the same table: the most-read documents a company sends become part of the customer experience stack – with the same personalization data, the same content governance and the same cloud platform as every other channel.

    Questions to settle

    1. Who owns the account statement in your company – marketing, operations, or IT?
    2. Which correspondence templates carry compliance-approved fragments that must be locked – and who approves changes to them?
    3. Where does correspondence data come from today, and can the Form Data Model bind to it directly?
    4. Does the front line need real-time document generation (Associate UI), or is batch enough?

    The channel everyone reads was the channel nobody designed. That excuse is gone.

    Frequently asked questions

    What changed with Interactive Communications in AEM Forms?

    With the June 2026 release (2026.6.0, 25 June), now generally available, Adobe moved Interactive Communications into AEM Forms as a Cloud Service. Customer correspondence – statements, bills, policy documents and welcome kits – is now authored in the browser, on the same cloud platform as website and campaigns. Previously, authoring required the Windows-only Desktop Designer.

    How is compliance controlled when correspondence is authored in the cloud?

    Through template locking. Layout and fragments such as headers, footers and legal disclaimers are locked at template level, and authors can only edit what governance allows. Versioning, annotation-based review and side-by-side PDF version compare give every correspondence change an audit trail, so the control sits in the authoring layer rather than being bolted on as a review step.

    What is a Form Data Model in AEM Forms?

    A Form Data Model is a visual mapping of document components to the data source, so that a statement renders per customer. It decides whether correspondence can bind directly to the data you already hold – which is the first question to settle before moving a template into the cloud.

    Working on this?

    Regulated correspondence in the cloud is mostly an accessibility and archiving question wearing a templating costume. Both are cheaper to solve before the first letter goes out.

    Get in touch →

    Sources: AEM as a Cloud Service release notes (2026.6.0) and Interactive Communications documentation on Adobe Experience League. Adobe and Adobe Experience Manager are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe. First published as part of my LinkedIn series, August 2026.

  • Meta blocks regulated-data audiences – and AEP now enforces it automatically

    Meta blocks regulated-data audiences – and AEP now enforces it automatically

    Your best Facebook audiences may stop working next quarter – and your marketing team won’t know why. Since June 8, Meta blocks any audience that carries health or financial data. Adobe Experience Platform now enforces this automatically: if a customer list touches a loan, a policy, a diagnosis or a prescription, it gets flagged and quietly switched off. No campaign, no delivery, no error that anyone notices.

    What shipped, exactly

    • June 4, 2026: AEP upgraded its Facebook destination to Meta Advertiser API v25. The restriction itself arrived with v24 and applies to every version from v24 onward – it is not optional and no longer version-specific.
    • The rule: audiences carrying regulated data (financial status, health) are blocked from activation to Meta.

    The architecture behind it

    Enforcement runs on Data Usage Labels. If an audience carries a governance label tied to financial status or health and is activated to the Facebook destination, AEP flags it – and Facebook blocks it from receiving data. There is no configuration path around it. The only two fixes Adobe documents: remove the restricted data from the audience, or contact Facebook directly.

    The architectural takeaway is bigger than one channel: consent and data-governance labels are no longer internal hygiene. Downstream partners now enforce them for you. If your labels are sloppy, you find out at the destination – in production.

    The fine print

    • This is Meta’s own rulebook, wired into the activation pipe – not an Adobe policy decision.
    • For a bank retargeting investment products or a pharma brand running a patient program, the core paid-social engine goes dark without an error message anyone watches.
    • The data that makes these audiences valuable is exactly the data Meta now refuses.

    Questions to settle

    1. Which of your active Meta audiences carry financial or health labels today – and who gets alerted when activation stops?
    2. Are your Data Usage Labels actually complete, or would a correct labeling pass switch off more audiences than expected?
    3. Where does the reallocated budget go – first-party journeys you own, or the next walled garden with the same risk?
    4. Who owns the channel-strategy decision this forces: marketing, data governance, or both?

    The fix isn’t technical. It’s strategic: rethinking which channels you trust with regulated data, and building first-party journeys you actually own. The teams that saw this coming keep their reach – the rest reallocate budget in a panic while the CFO asks why last quarter’s numbers slipped.

    Also on labels and consent in a pharma stack: HCP portal, part 2 – the HCP sees one seamless portal, the data walks a permission chain.

    Frequently asked questions

    Why do Meta audiences carrying health or financial data stop working?

    Since 8 June, Meta blocks any audience that carries health or financial data. The restriction arrived with the Meta Advertiser API v24 and applies to every version from v24 onward, so it is neither optional nor version-specific. Adobe Experience Platform upgraded its Facebook destination to v25 on 4 June 2026.

    How does Adobe Experience Platform enforce the Meta restriction?

    Through Data Usage Labels. If an audience carries a governance label tied to financial status or health and is activated to the Facebook destination, AEP flags it and Facebook blocks it from receiving data. There is no configuration path around it: the only two fixes Adobe documents are removing the restricted data from the audience, or contacting Facebook directly.

    What does this mean for data governance labels in general?

    That labels are no longer internal hygiene. Downstream partners now enforce them on your behalf, which means incomplete or sloppy labelling is discovered at the destination and in production rather than during an internal review.

    Working on this?

    Automatic enforcement is good news, and it also means an audience you relied on may stop activating without warning. Worth knowing which of yours are affected before a campaign finds out for you.

    Get in touch →

    Sources: Adobe Experience Platform release notes (June 2026) and the Facebook destination documentation (restricted data handling) on Adobe Experience League. Adobe and Adobe Experience Platform are trademarks of Adobe Inc.; Meta and Facebook are trademarks of Meta Platforms, Inc. This is an independent analysis; no partnership with or endorsement by either company. First published as part of my LinkedIn series, July 2026.