Hey Target practitioners, we recently shipped two new popularity-based criteria in Adobe Target Recommendations: Most Viewed by Profile Attribute and Top Sellers by Profile Attribute. In this post I want to walk through what these criteria do, how they differ from the existing popularity options, what kinds of personalization scenarios they make possible and finally an end-to-end example showing how this feature can be used.A short video walkthrough of the complete setup is available here: Feature Walkthrough VideoWhat was already there What is new Use cases Setting it up: an end-to-end example DocumentationWhat was already thereTarget already provided several popularity-based criteria covering two signals (most viewed and top sellers) across three scopes:  Most Viewed Top Sellers Across the site Most Viewed Across the Site Top Sellers Across the Site By item category Most Viewed by Category Top Sellers by Category By item attribute Most Viewed by Item Attribute Top Sellers by Item Attribute The "Across the site" criteria rank items across all your traffic. The "By item category" criteria scope that down to behavior within a specific item category. The "By item attribute" criteria let you go further and group by any entity attribute in your catalog, like brand or product type. All six are useful, but in every case the grouping is based on the item. What the visitor looks like (their region, loyalty tier, industry, or any other profile attribute) plays no part in determining which ranked list they receive. What is newThe new criteria bring the visitor into the picture. You pick a profile attribute that is meaningful for your business (region, plan type, loyalty tier, etc.) and the algorithm builds a separate "most viewed" or "top sellers" list for each distinct value of that attribute. To make this concrete: say you have a profile attribute "Region" capturing the visitor's geographic location. A visitor with Region=US sees a list ranked by what other US visitors have been viewing most. A visitor with Region=India sees a completely different list, built from India visitor behavior.The result is that two visitors on the same page, looking at the same recommendation slot, can see entirely different content. Not because of what they personally clicked on, but because of what people like them tend to find valuable. It brings the "wisdom of the crowd" idea down from the site-wide level to the segment level. Use casesHere are some example use cases that can be achieved using these new criteria.Geography-based trending content. In media and e-commerce, what trends in one market often has little to do with what trends in another. Segmenting "most viewed" by region means your audience in smaller markets sees recommendations grounded in their peers' behavior, not a global chart skewed by your highest-traffic region.Subscription tier. Free and premium users tend to engage with content very differently. Rather than showing both groups the same popularity list, you can surface what free users browse most to free users, and what premium subscribers engage with most to premium subscribers.Age group. A retail or media brand serving a wide age range can show each group what people like them are engaging with most, rather than a popularity list dominated by the largest demographic in their user base.More broadly, these criteria work with any visitor attribute you can capture in a Target profile, so the segmentation possibilities extend well beyond these examples. Setting it up: an end-to-end exampleTo make this concrete, here is a walkthrough using a retail site that wants to surface the most-viewed products by country. The same steps apply for any other profile attribute.Step 1: Create a profile scriptA profile script is used to set the profile attribute for a visitor and make it available to the criteria to use it while generating recommendations. (Know more about Profile scripts) Go to Audiences > Profile Scripts > Create Script name your script with the recsAttribute prefix, for example recsAttributeCountry. Only scripts with the recsAttribute prefix appear as options when configuring the criteria later. Write the script to capture the value of the profile attribute. For example, if your page sends the country of the visitor as a mbox parameter, it can be captured using: var country = user.get('recsAttributeCountry');if (!country) { country = mbox.param('country');}return country; Save and activate the profile script. Step 2: Create the criteriaGo to Recommendations > Criteria > Create Criteria Set the algorithm type to Popularity-Based Select one of the two profile attribute based algorithm options: Most Viewed by Profile Attribute Top Sellers by Profile Attribute Profile Attribute: select your profile script from the dropdown — it appears without the recsAttribute prefix, so recsAttributeCountry shows as Country Set the lookback window, entity type, and any inclusion rules Save the criteria.Step 3: Use the criteria in an activityAdd the criteria to a Recommendations activity and assign it to the mbox on your page. The recommendations will be ready after the next criteria run based on the lookback window you selected.Once the criteria has run, you can download the generated data file via the Download Data option to verify the output. The entries will look something like this:"Country=INDIA,item-012,item-015,item-011,item-020""Country=UK,item-007,item-008,item-009,item-006""Country=US,item-019,item-017,item-005,item-001"Each row is a separate ranked list for a distinct country value observed in your session data.Fetching recommendations from your pagePass the attribute value as a parameter in your getOffer call. Target reads it at request time, the profile script maps it to the visitor's profile, and the criteria uses it to return the right ranked list:adobe.target.getOffer({ mbox: 'your-recs-mbox', selector: '#recommendations-container', params: { 'country': 'UK' }, success: function(offer) { adobe.target.applyOffer({ mbox: 'your-recs-mbox', selector: '#recommendations-container', offer: offer }); }});The value of the country parameter can come from anywhere — a URL parameter, a cookie, a user preference, or a geo-lookup.What happens at request timeWhen the getOffer call fires, Target executes the following before returning recommendations:The profile script runs. If the visitor does not yet have a value for this attribute, it reads the mbox parameter (e.g. country=UK) and stores it on the visitor's profile. If a value is already stored from an earlier request in the visit, that value is reused. The criteria picks up the attribute value and looks up the pre-computed ranked list built from interactions by other visitors who had the same attribute value. That ranked list is returned and rendered on the page.This all happens in a single request response cycle. The country parameter only needs to be passed once per visitor, once the profile attribute is set, it will be reused in the given example profile script. Later calls for the same mbox, even on pages that don't pass country at all, still resolve the correct recommendation, since the profile script in our example reuses the value already stored on the visitor's profile. This behavior comes from the script itself, not from Target automatically remembering the value: if the script were written to recompute from the parameter on every call instead (for example, the script is return mbox.param('country')), the parameter would need to be included on every getOffer call, since each run would overwrite whatever was there before, including overwriting it to blank if the parameter happens to be missing on that call. When the attribute resolves to blank, the lookup finds no matching ranked list, and depending on whether a backup is configured for the criteria, either no recommendation is returned, or the backup recommendation is served instead. DocumentationPopularity-based criteriaIf you have questions or run into anything while setting this up, do let us know by leaving a reply on this post.

We’re always looking for ways to improve your experience in AEM Sites Optimizer and would like to speak with customers who are hands-on in the product. Who we’re looking for✓ Current AEM Sites Optimizer users✓ Users who work with content authoring, code authoring, or both✓ Users who have recently made an optimization using the recommendations provided by AEM Sites Optimizer What we ask of participants45 - 60 minutes of your time to share your process for completing a recent optimization and answer interviewer questionsTimelineSign-up window: Today through September 25 Interviews running this week and nextHow to participateClick here to schedule a session with our research team. Please reach out if you don’t see a time that works for you.Questions?Ask below — the product team will be monitoring this thread throughout the sign-up period.

Learn more about Adobe Marketo Optimizer.The Lighthouse Program gives a small group of Marketo Engage users the chance to try Adobe Marketo Optimizer for free during a focused testing period. Adobe Marketo Optimizer helps you engage customers across every channel and continuously improve results with AI at the core. With AMO, you can:Optimize with AI - let AI-powered decisioning and insights surface what's working, recommend next best actions, and continuously improve campaign performance  Engage across channels - reach customers with connected, coordinated experiences across multiple channels Build journeys visually - design, adjust, and orchestrate customer journeys on an interactive journey canvas, no guesswork requiredWhat you'll get access toDuring the program, you'll be able to test person journeys, emails, and forms, plus a wealth of agentic skills that help you investigate your Marketo data and optimize your workflows.As a Lighthouse participant, you'll: Get early, hands-on access to Adobe Marketo Optimizer and its newest capabilities Work directly with our product team and share feedback that shapes the roadmap Help set the direction for a product built around real customer needs—yoursOnboarding and supportYou won't be on your own. Participants get weekly meetings with our product management team, onboarding materials including demo videos and documentation, and direct access to our team for questions along the way.Who can joinAll Marketo Engage users are eligible.What we ask in returnTest Adobe Marketo Optimizer with your own production campaigns and data, with the goal of building out at least one end-to-end, real-world use case. (Because so much of AMO's value comes from AI, testing against real production data is where you'll see what it can really do.)  Share candid feedback through surveys, interviews, and a dedicated feedback channelHow selection worksSpots are limited. Fill out the form below to apply. There's no fixed deadline, but the form will close once spots are filled, so we encourage you to apply early. If you're selected, our team will reach out to schedule a time to talk through next steps. If you haven't heard from us within a few weeks, you can assume the spots have been filled this round.What happens after the programThe program runs from 9/28 through 12/31. When it ends, access to Adobe Marketo Optimizer will end as well, unless you choose to purchase it or other arrangements are made.  

Save time writing scenario summaries — click Describe with AI in a scenario’s Settings panel and Fusion will generate a clear, human‑readable description for you automatically, based on the modules and configuration in the scenario.OverviewThis release adds a Describe with AI action to the Description field in a scenario’s Settings panel. When invoked, Fusion analyzes the modules, connections, triggers, and mapped outputs in the scenario and produces a concise description you can accept, edit, or discard. The feature is designed to help teams keep scenario metadata accurate and useful without having to compose descriptions manually. What’s newDescribe with AI button — One‑click generation of a scenario description from the Settings panel description field. Context‑aware summaries — The generated text reflects the scenario’s modules, triggers, key connections, and primary outputs so descriptions are actionable and relevant. Edit and accept flow — Generated descriptions are presented in an editable dialog so you can tweak phrasing, add business context, or preserve version notes before saving. Non‑destructive — Using Describe with AI does not overwrite existing descriptions unless you choose Save; you can always revert to the previous text.Why this mattersGood scenario descriptions help operators, reviewers, and new team members understand intent, ownership, and risk without opening the canvas. Describe with AI reduces friction when documenting automations, improving discoverability and maintainability across teams:Faster documentation — Spend less time writing routine summaries and more time on design and validation. Consistent quality — AI‑generated descriptions follow a clear, concise style that improves readability across your org. Onboarding & governance — Accurate descriptions make it easier to triage, hand off, and audit scenarios.How to get startedOpen Fusion and navigate to the scenario you want to document. Click the gear icon to open Settings and locate the Description field. Click Describe with AI. Fusion will analyze the scenario and present a suggested description in an editable dialog. Review and edit the suggested text as needed, then click Save to update the scenario description. Test the workflow on a few scenarios to confirm the summary style meets your team’s needs, then adopt it as part of your scenario‑documentation process.Behavior and tipsStart with scenarios that have clear triggers and outputs — the AI produces the best results when there is sufficient contextual structure to analyze. If a generated description is missing business context, add brief notes (owner, SLAs, or related docs) before saving so future readers get the full picture. Use Describe with AI as a starting point — the editable dialog lets you align tone and terminology with your team’s conventions. Where to find documentationSee Experience League for full details on configuring scenario settings and examples:Configure scenario settings — Experience LeagueNeed help or want to give feedback?If you have questions, encounter issues, or want to suggest improvements (for example, tone templates, team‑level style presets, or the ability to include linked docs automatically), please:Post a comment on the Experience League article Start a thread in the Experience League Community Contact Adobe Support through the Admin Console Support portalYour feedback helps us improve the Describe with AI experience and prioritize future enhancements. 

You can now authenticate your Salesforce connections using PKCE (Proof Key for Code Exchange) in addition to standard OAuth 2.0, and enable Refresh Token Rotation for improved long‑term credential security. When creating a Salesforce connection, choose the authentication method from the new Connection type dropdown.OverviewThis update adds two security‑focused options to the Salesforce connector: PKCE for secure, browser‑based authorization flows (recommended for public clients and scenarios where a client secret cannot be safely stored), and Refresh Token Rotation (RTR) to automatically rotate refresh tokens and reduce risk from long‑lived credentials. What’s newPKCE (Proof Key for Code Exchange) — Authenticate without a client secret by using a code verifier/challenge flow. Useful for public clients or environments where storing a client secret is not desirable. Refresh Token Rotation (RTR) — Optionally enable RTR for Salesforce connections so refresh tokens are rotated on each use. This reduces exposure from token theft and aligns with modern security best practices.Why this mattersThese enhancements strengthen the security and flexibility of Salesforce integrations in Fusion:PKCE removes the need to store a client secret for browser‑based or public integrations, lowering the risk of credential leakage. Refresh Token Rotation reduces the window of opportunity for misuse if a refresh token is compromised and supports better long‑term credential hygiene.How to get startedOpen Fusion and create or edit a scenario. Add or edit your Salesforce connector module and open the connection dialog. In the Connection type dropdown, select either OAuth 2.0 or PKCE based on your environment and security requirements. If PKCE is selected, follow the guided authorization steps in the dialog — Fusion will generate the code challenge and complete the PKCE flow for you. Refresh Token Rotation, should be enabled on Salesforce setup. Test the connection in a non‑production environment to confirm authentication and token rotation behavior before deploying to production. Before you startReview your organization’s security and compliance policies for OAuth client configuration and token rotation. Ensure the connected Salesforce app is configured to allow the PKCE flow and RTR if you plan to enable them. Salesforce admin privileges may be required to adjust the connected app. Plan to test in a non‑production org or sandbox before enabling RTR in production scenarios.Where to find documentationSee Experience League for full Salesforce module reference and connection field details:Experience League — Salesforce modules and their fieldsNeed help or want to give feedback?If you have questions, run into issues, or want to suggest enhancements (for example, improved RTR monitoring, connection migration tools, or templated PKCE setup for common Salesforce orgs), please:Post a comment on the Experience League article Start a thread in the Experience League Community Contact Adobe Support through the Admin Console Support portalYour feedback helps us prioritize future improvements. 

Two new MCP connectors bring conversational, model-driven automation to Fusion. Instead of wiring together many individual modules, a single MCP module accepts an open-ended instruction and lets an AI model determine which Workfront or AEM operations are needed to fulfill it.OverviewThis release adds two first‑party connectors that speak to Adobe's Model Context Protocol (MCP) server: Adobe Workfront MCP and Adobe AEM MCP. Each connector exposes a single, flexible module you place on a scenario canvas and drive with natural‑language instructions (prompts). The MCP module synthesizes the required API calls, executes them, and returns a consolidated, human‑readable result — reducing the need to build long chains of Get/Filter/Transform/Write modules for many common tasks.What’s newSingle conversational module — One module accepts an instruction and lets the MCP model plan and run the necessary Workfront or AEM operations, returning a synthesized answer or structured output. Task examples — Ask the module to summarize active projects behind schedule, bulk-annotate assets based on content, find and tag orphaned files, or generate a prioritized list of at‑risk work items — without manually composing multiple connector calls. Action restrictions & safe mode — Define an allowlist or denylist of permitted Workfront/AEM operations so unattended scenarios cannot perform unexpected destructive actions (for example, disallow Delete or Update actions and allow only Read/List). Default Adobe Managed AI — Out of the box the MCP module uses Adobe Managed AI backed by the claude‑sonnet‑5 model for planning and synthesis. Bring your own model (BYOM) — Optionally configure the module to call a different LLM by supplying a model key and credentials. The MCP runtime will route instructions to the model you provide while still enforcing the action restrictions you’ve set. Structured and human responses — Receive either a synthesized narrative summary or structured JSON with the model’s chosen actions and results for downstream scenario processing. Auditable plan preview — Before executing, optionally request the model to return a proposed step plan (which modules/actions it intends to run) so you can review and approve in interactive or CI/CD flows.Why this mattersThe MCP connectors reduce scenario complexity and development time by moving orchestration logic into a model that can reason across resources and operations. Common benefits include:Faster automations — Build fewer modules: one instruction can replace multi‑step flows that previously required Get → Filter → Transform → Write sequences. Better human‑readable outputs — The model synthesizes and summarizes results, making outputs easier to consume for stakeholders and downstream notifications. Flexible interactions — Non‑developers can drive automation through prompts without deep knowledge of each connector’s API surface. Safer unattended runs — Action restrictions and an optional plan preview let Ops and security teams approve or limit what the model may change. Model choice — Use Adobe Managed AI for a turnkey experience or plug in a different LLM when you need specific models, fine‑tuning, or data residency requirements.How to get startedOpen Fusion and create or edit a scenario. From the connector list, add either the Adobe Workfront MCP or Adobe AEM MCP module to your canvas. Create a connection to the MCP server (Adobe Managed AI is configured by default). If you want to use a different model, provide the model endpoint/key and any required credentials in the connection settings. Author your instruction in the module’s prompt field. Examples: “Find all active projects that are behind schedule and summarize their status, including top three blockers and suggested next steps.” “Identify AEM assets with missing metadata that reference ‘summer campaign’ and add the 'campaign:summer' tag.” Configure allowed actions — select which Workfront/AEM API actions the model may invoke (Read/List/Update/Create/Delete). Enable Safe Mode (Read-only) for discovery scenarios. Map the module’s outputs into downstream modules (for example, send the synthesized summary to Slack, create a Workfront report, or write structured results to a datastore). Test in a non‑production org or team, then publish and schedule or trigger as required.Behavior and tipsStart with conservative allowlists — allow Read/List first, validate the model’s step plans, then expand permissions to Create/Update if needed. Use clear, explicit prompts. If you require non‑destructive behavior, include it in the instruction (for example, “Do not delete anything; only suggest items to delete.”) and enforce with the connector’s action restrictions. When using BYOM, verify the model’s latency and cost characteristics and test prompt reliability in a staging environment before production roll‑out. Enable Plan Preview for high‑risk instructions so you can review the model’s intended actions and catch mistakes before they run. Combine MCP outputs with existing Fusion modules — for example, use the model’s structured result to feed a bulk Update or to create tickets in your ITSM system. Audit logs and activity exports are recommended for governance: pair MCP scenarios with Insights or activity exports so you can trace which automated actions were executed and by which scenario.Before you startReview organizational policies on AI usage, data sharing, and model selection. BYOM may require additional approvals for external model keys. If you plan to allow Update or Delete actions, coordinate with Team leads to ensure scenarios run in appropriate test environments first.Where to find documentationSee Experience League for full connector documentation, prompt examples, and security guidance:Experience League — Workfront MCP connector documentation Experience League — Workfront MCP documentation Experience League — AEM MCP documentation   Need help or want to give feedback?If you have questions, encounter issues, or want to suggest improvements (for example, richer plan visualization, templated prompts for common workflows, bulk operation safety controls, or additional model integrations), please:Post a comment on the Experience League article Start a thread in the Experience League Community Contact Adobe Support through the Admin Console Support portalYour feedback helps us prioritize future enhancements. 

You can now access your Fusion objects from inside a scenario. The new Workfront Fusion connector lets scenarios call Fusion’s own API to create, inspect, modify, and operate Fusion resources.OverviewThis release introduces a first‑party Workfront Fusion connector that exposes Fusion APIs directly inside the scenario canvas. Use it to back up or clone scenarios, inspect dependencies, export activity logs, and gather operational telemetry — all as part of your automation flows.What’s newFull record lifecycle — Create, read, update, delete, list, and clone Fusion records from scenarios. Dependency insights — Retrieve a record’s dependencies so you can understand or safely update resources that are referenced elsewhere. Activity exports — Export activity logs for auditing, troubleshooting, or archival workflows. Queue and hook visibility — List hook queues, read queue items, and get queue statistics to monitor trigger backlogs and failure patterns. Connection & scenario mapping — List scenarios that reference a specific connection to find downstream impact before making changes. Regions & orgs — Enumerate the Fusion regions and organizations available to your authenticated identity.Included API v3 changes (September 2, 2026)This connector includes the latest public API v3 additions and a set of modified responses and request behaviors. Highlights: Why this mattersPlatform and Ops teams can now incorporate Fusion administration directly into automation pipelines. Common use cases include:Automated provisioning of scenarios in CI/CD flows. Org-wide impact analysis by enumerating which scenarios reference a connection before rotating credentials or removing an integration. Operational monitoring by exporting activity logs and queue statistics into observability or ticketing systems for alerting and root cause analysis. Safe cloning and versioning workflows that capture or continue processing state with the new clone options.How to get startedOpen Fusion and create or edit a scenario. Add the new Workfront Fusion connector module to your canvas and create a connection (it authenticates to Fusion using the same pattern as other first‑party connectors). Choose the operation you need (for example, List scenarios, Clone scenario, Get hook queue statistics, Export activity logs). Map inputs and outputs into your scenario flow — for example, list scenarios that reference a connection, iterate, and notify owners or disable impacted scenarios. Test in a non‑production org or team, then publish and schedule or trigger as required.Where to find documentationSee Experience League for full API references, connector documentation, and examples:Workfront Fusion connector documentation Workfront Fusion public API v3 referenceNeed help or want to give feedback?If you have questions, encounter issues, or want to suggest improvements (for example, bulk scenario cloning options, richer dependency graphs, or additional admin endpoints), please:Post a comment on the Experience League article Start a thread in the Experience League Community Contact Adobe Support through the Admin Console Support portalYour feedback helps us prioritize future enhancements. 

New: A faster way to see what broke — Failed Executions Logs in the Insights dashboardWhen multiple scenarios fail across your org, tracking down how many, which ones, and why used to mean opening scenarios one-by-one. The new Failed Executions Logs widget surfaces every failed execution across every scenario in a single table so you can triage incidents fast, at scale.OverviewThe Failed Executions Logs widget lives on the new Insights page (which now also contains the Performance widget). It aggregates failed executions across your organization into a single, filterable table so you get the full picture quickly — no more stitching together results from individual scenario pages.What’s newCentralized failure list — See every failed execution across every scenario in your organization in one table. Powerful filters — Filter by team, scenario, type, error message, and date range. Each filter supports "only these" or "everything except these" to help narrow or exclude results quickly. Reactivate from the table — Deactivated scenarios appear in the table and can be selected and reactivated directly from the widget to speed recovery. Insights home — The widget is part of a larger Insights page that now houses Performance charts (previously on their own page) and will grow with more widgets for org-wide visibility and monitoring.Why this mattersWhen outages, expired credentials, or upstream failures cause many scenarios to fail, Ops and platform owners need a single, accurate view to triage and prioritize fixes. The Failed Executions Logs widget reduces mean time to detect and mean time to remediate by letting you find the worst offenders, filter by teams or error patterns, and take corrective action without hopping between scenario pages.How to get startedOpen Fusion and click Insights in the left navigation to open the Insights dashboard. Locate the Failed Executions Logs widget on the page (it’s grouped with Performance widgets). Use the Pool selector near the upper-left if you want metrics scoped to a specific worker pool. Apply filters (team, scenario, type, error message, date range). Use "only these" or "except these" options to refine results. Click a row to view the error details; select deactivated scenarios to reactivate them directly from the table when appropriate.Behavior and tipsCombine content filters with date ranges (for example, last 24 hours + specific team) to focus on recent incidents without historical noise. When reactivating a scenario from the table, verify the underlying cause (credentials, connector health, downstream service) before resuming high-volume runs. Pair the Failed Executions Logs with the Performance charts on Insights to correlate failures with execution backlog, pool utilization, or spikes in execution volume.Where to find documentationSee the Experience League article for full details on the Insights dashboard and its widgets: View the Fusion Insights Dashboard.Need help or want to give feedback?If you have questions, encounter issues, or want to suggest enhancements, please post a comment on the Experience League article, start a thread in the Experience League Community, or contact Adobe Support via the Admin Console. Your feedback helps us prioritize future improvements. 

Workfront Fusion — Native Adobe Storage (ESM) supportWorkfront Fusion now natively supports Adobe Storage (ESM)Workfront Fusion now connects directly to Adobe cloud storage (Enterprise Storage Management, ESM). Browse and upload assets inside Fusion, automate store lifecycle and access, and generate presigned URLs for secure read/write integrations with external systems.OverviewThis release adds native Adobe Storage support in Fusion using the same ESM layer that powers the Workfront/Frame.io unified review and approval experience and is shared across Frame.io, Document Cloud, and Creative Cloud. You’ll see a new Storage navigation menu for browsing and uploads, plus Adobe Storage modules you can use in scenarios to manage stores, collaborators, and presigned URLs.What’s newStorage navigation — A new Storage menu item in Fusion to browse ESM stores and upload files without leaving the app. Store lifecycle — Create, discard, restore, and delete ESM stores from scenarios for automated provisioning and cleanup. Collaboration management — Invite users to collaborate with explicit role, sharing scope, and notification controls. Presigned URL support — Generate Presigned URL and Generate Upload URL modules so external systems can read from or write to ESM stores securely without routing files through Fusion or sharing standing credentials. Custom API calls — Use a generic/custom action to call Adobe Storage API endpoints for operations not yet covered by built‑in modules.Why this mattersBecause Fusion talks directly to Adobe cloud storage (ESM), you can integrate storage operations into existing review, approval, and asset workflows used by Workfront and Frame.io. The presigned URL modules are especially important for content supply chains: they let other systems push or pull large assets securely and efficiently without moving files through Fusion or exposing long‑lived credentials.Before you startThese modules operate on ESM stores. If your organization still uses legacy Workfront storage, enable Adobe cloud storage first — see the links in Documentation below.How to get startedConfirm Adobe cloud storage (ESM) is enabled for your organization. Open Fusion, click the new Storage menu to browse or upload assets, or initialize the connection with Adobe Storage. Start using Adobe Storage modules for collaboration, presigned URLs, or custom API modules.Behavior and tipsStore operations act at the ESM store level — review retention, governance, and access policies before automating deletions or discards. When inviting collaborators, choose roles and notification settings deliberately to avoid unintended access or notification volume. Presigned URLs are time‑limited. Use short lifetimes for public or untrusted clients and rotate keys/credentials regularly. Test custom API calls and presigned URL workflows in non‑production environments to validate scopes, request formats, signed headers, and error handling.DocumentationAdobe Storage modules referenceAdobe cloud storage overview (ESM)Enable Adobe cloud storage for your organizationNeed help or want to give feedback?If you have questions, run into issues setting this up, or want to suggest improvements (for example, bulk presigned URL generation, scoped role templates, or richer Storage UI features), post a comment on the Experience League article, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize future enhancements.Questions or want help designing a scenario that uses Adobe Storage modules or presigned URL flows? Drop them below.  

Packages is now generally available in Workfront Fusion — build and run your own custom JavaScript functions, backed by Adobe App Builder, and use them directly in your scenario mappings.OverviewPackages let you build and run your own custom logic inside Fusion, without leaving the Fusion interface. When the standard modules don't do exactly what you need, you can write a function to transform data, do a calculation, call an external service, or wrap a routine you want to reuse — then test it, publish it, and call it from your scenarios. A package can bundle everything a function needs: the function itself, reusable variables (like a base URL or API key), outside library dependencies, and automatic version history.What's newFunctions — Write custom logic in JavaScript, define typed inputs, test drafts safely before publishing, and republish or unpublish live functions as needed. Variables — Store reusable values (URLs, IDs, keys) once and reference them across functions. Mark variables secret to keep sensitive values hidden, or public to use them directly in the scenario designer. Dependencies — Install outside libraries (for example, axios or lodash@4.17.21) that your functions rely on. History — Every draft save is kept automatically, so you can review or restore an earlier version before publishing.How to get startedClick the Packages tab in the left navigation panel and initialize the runtime environment (one-time setup, tied to an Adobe App Builder project). Click Create package, give it a name, and start building functions in the Functions area. Use the Adobe App Builder connector's Use function from package and Use variable from package modules to bring your custom logic and variables into a scenario.Using Packages requires an Adobe App Builder license — see access requirements for details.For full setup instructions, see Use custom function packages. 

Connect Azure DevOps to Workfront Fusion using a service principalYou can create a connection that uses a service principal (an Application API connection) instead of a personal account. Use this when you want the integration to run as an application or service identity rather than a specific person — for example, to avoid breakage when someone leaves the company or changes credentials. This connection type is available for all Azure DevOps modules.OverviewService principal connections let Fusion authenticate to Azure DevOps as an application identity (an app registration in Microsoft Entra ID) using a client secret. After you register the app and add it as a user in your Azure DevOps organization, create a Service Principal connection in the Azure DevOps module and provide the Tenant ID, Client ID, Client Secret, and organization name.NOTE: Service principal authentication does not support every Azure DevOps feature. A small number of admin-level actions — for example, managing user licenses or other tenant-admin-only tasks — still require a personal account connection. Use a service principal when you only need work items, boards, repos, pipelines, and similar non-admin operations.PrerequisitesGlobal Administrator or Application Administrator access in Microsoft Entra ID to create the app registration (or have your identity team perform this step). Project Collection Administrator access in your Azure DevOps organization to add the service principal as a user. The name of your Azure DevOps organization (the segment in dev.azure.com/<your organization name>).Step 1 — Create the app registration in Microsoft Entra IDSign in to the Microsoft Entra admin center. Go to App registrations > New registration. Give the app a clear name (for example, Workfront Fusion Azure DevOps Integration). Leave Redirect URI blank — this connection does not use interactive browser sign-in. Select Register.Step 2 — Create a client secretOpen your new app registration and go to Certificates & secrets. Select New client secret, add a description, choose an expiry, and select Add. Copy the secret Value immediately — it is shown only once. If you navigate away you must create a new secret.Step 3 — Collect the connection detailsFrom the app registration Overview page, note the following values for the connection setup:Tenant ID — Directory (tenant) ID on the Overview page. Client ID — Application (client) ID on the Overview page. Client Secret — The secret Value you copied. Organization — Your Azure DevOps organization name (the folder in dev.azure.com/yourorg).NOTE: You can skip adding API permissions in the app registration. Azure DevOps does not expose application permissions via the Azure portal the same way; access is granted directly inside Azure DevOps (next step).Step 4 — Add the service principal to your Azure DevOps organizationSign in to your Azure DevOps organization at dev.azure.com/<your organization name>. Open Organization settings (lower left) > Users, then select Add users. Search by the app's display name (the name you registered in Entra). Do not search by Client ID. Select an access level: Basic — usually sufficient for reading/writing work items, boards, repos, and pipelines. Project Collection Administrators — required only if your workflow must browse or manage collection-level processes (Agile, Scrum, custom templates) during setup. Grant this only when necessary. Assign the app to the specific project(s) it needs and select Add.Step 5 — Create the connection in Workfront FusionOpen an Azure DevOps module in the Fusion canvas and start creating a new connection. Select the Service Principal (Application API) connection type. Enter Tenant ID, Client ID, Client Secret, and Organization. Save the connection. If the app registration and Azure DevOps user mapping are correct, the connection will validate successfully.Behavior and tipsUse a service principal for non-personal, long-lived integrations so they don’t break when people change accounts. If a workflow requires collection‑level configuration discovery (process templates) you may need to add the app to Project Collection Administrators during setup — otherwise Basic is usually enough. Test the connection with the modules you plan to use (work items, repos, pipelines) to confirm permissions are adequate before switching production scenarios over to the service principal. Rotate client secrets periodically and update the Fusion connection when you create a new secret to avoid unexpected outages. Keep descriptive app names and notes in both Entra and Azure DevOps so admins recognize the purpose and environment (dev/staging/prod).Where to find documentationFor step-by-step guidance and troubleshooting, see the Experience League documentation for Azure DevOps connector setup and Microsoft Entra ID app registration. Need help or want to give feedback?If you have questions, encounter issues, or want to suggest improvements (for example, clearer permission guidance, service principal role templates, or programmatic management of connections), post a comment on the Experience League article, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize future enhancements. 

 Workfront Fusion Custom UI extensions OverviewFusion can display your own web UI inside its interface. Build a small web app (a guest extension), publish it via Adobe App Builder, and Fusion will show a new menu item in its navigation that opens your UI in the main canvas. The guest automatically receives context such as the signed‑in user, organization, team, and other metadata so your extension can adapt to the current environment.The technology underneathYour guest is built with two Adobe technologies:Adobe App Builder — Free hosting and tooling for small web apps and serverless actions. App Builder hosts your static UI on Adobe’s CDN and provides the aio CLI to create, build, and publish the app. Adobe UI Extensibility SDK (UIX) — The libraries that let host and guest talk. Use @adobe/uix-guest in your guest; Fusion uses @adobe/uix-host on its side.Extension pointsAn extension point is a named slot in Fusion where a guest may appear. Extension point names use the format: service/name/version.Fusion currently offers these extension points:Extension point Where it appears When to use it fusion/nav-organization/1 Under the Organization section of the left navigation Your tool is about the whole organization fusion/nav-team/1 Under the Team section of the left navigation (when a team is selected) Your tool is about a specific team An extension can implement one or both points; Fusion adds a navigation menu item with the extension title for the chosen slot(s). Clicking the button opens your UI in the main content area.How to get startedInstall the App Builder CLI (aio) and create a new App Builder app using the UIX guest template. Implement your UI and install @adobe/uix-guest. Initialize the UIX guest client to receive context and messages from Fusion. Test locally with the aio dev workflow and verify the guest receives expected context (user, org, team). Build and publish the app to App Builder (the app is hosted on Adobe’s CDN). Register the extension in Fusion: provide the extension metadata, choose the extension point(s), and supply the hosted URL for your guest. Verify the extension appears in Fusion navigation and validate behavior in target organizations/teams.Behavior and tipsUse the UIX guest API to request context, listen for navigation events, and send messages back to the host as needed. Keep payloads and interactions minimal: rely on the host for authentication and context; perform sensitive server‑side work in actions hosted on App Builder when needed. Test your extension across environments (dev, staging, prod). Use descriptive extension names and notes so admins can identify the intended environment and purpose. Review permissions and security: App Builder hosts your assets on Adobe’s CDN; design auth and server interactions to validate user identity and scope where required.Where to find documentationFor detailed step‑by‑step guidance, code samples, and publishing instructions, see the Experience League documentation:Custom UI extensions: readme on Experience LeagueNeed help or want to give feedback?If you have questions, run into issues, or want to suggest improvements (for example, additional extension points, deeper host APIs, or streamlined publishing), post a comment on the Experience League article, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize enhancements.  

 Search input and output bundles in scenario executionsPreviously you could not search the actual input and output bundles shown in an execution. Now you can search both input and output bundles directly from the execution UI — use the module/filter output search bars or the execution search to find specific bundle content, IDs, or events.OverviewWe’ve added the ability to search the text and metadata inside bundle payloads for both inputs and outputs in an execution. This makes it much faster to locate a particular bundle, debug processing logic, or verify that expected data passed through a specific step. You can search at the module/filter level or across the entire execution timeline.What’s newSearch the contents of input bundles shown for a module or filter. Search the contents of output bundles shown for a module or filter. Combine content searches with status filtering to surface only Success, Warning, Failed, Passed, or Failed bundles as applicable.How to search bundle contentOpen the scenario and select the execution you want to inspect. To view a module’s input/output, click the details bubble next to the module. The number in the bubble is the count of bundles the module produced for that execution. In the module output panel, use the search bar to search the text and metadata inside input and output bundles. Results update immediately to show matching bundles Refine searches by status: use the Status Filter dropdown in the search panel to show only Success, Warning, Failed, Passed, or Failed bundles.Behavior and tipsSearches operate on the entire payload and metadata returned by the module. Combining content search with status filters (for example, search for an order ID and show only Failed bundles) helps isolate problematic records faster.Where to find documentationYou can learn more about viewing execution history on Experience League: see the View a specific scenario execution.Need help or want to give feedback?If you have questions, encounter issues, or want to suggest improvements (for example, saved bundle searches, regex search, or direct links from execution search results to bundle payloads), post a comment below, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize future enhancements. 

 Workfront Watch Event modules secured by default with authTokenEffective August 23, 2026, all Workfront Watch Event module subscriptions — including existing ones — will be protected by authToken-based verification by default. This ensures payloads delivered to your Fusion scenarios can be validated as originating from Workfront.OverviewTo improve webhook security, Fusion will be enabling authToken validation by default for the Watch Event modules. The authToken is a shared secret included with every webhook delivery so your receiving endpoint can verify the request before processing it. This change applies to both new subscriptions and any Watch Event modules you already have in active scenarios.What’s changingAll Workfront Watch Event module subscriptions will include an authToken with delivered payloads by default starting August 23, 2026. Fusion will automatically apply this security setting to existing Watch Event module webhooks — no manual migration or reconfiguration is required.Why it’s changingWithout a shared secret, webhook endpoints cannot distinguish legitimate Workfront events from spoofed requests. A discovered webhook URL is otherwise open to anyone. The authToken provides a simple, effective way for your endpoint to validate that requests truly came from Workfront before taking action.What this means for youOn August 23, your existing Watch Event module scenarios will be secured by default; payloads will include an authToken you can verify at the receiver. No action is required to receive this protection: the setting will be enabled automatically for existing Watch Event subscriptions.If you need to turn it off (compatibility only)If a webhook breaks after this change and you need to disable authToken for compatibility, perform these steps before August 23, 2026:Open the scenario that contains the Watch Event module. Edit the module’s webhook. Disable the Enable secured hooks option. Save the module and re-activate the scenario.We strongly recommend leaving authToken verification enabled unless your receiving endpoint explicitly cannot support it — disabling the setting removes the ability to verify that requests are genuinely from Workfront. Where to find documentationFor technical details about the underlying mechanism and how to validate tokens, see the Event Subscription API docs and the Workfront / Workfront Planning connector documentation on Experience League:Fusion release notes (2026-08-10) Event Subscription API documentationNeed help or want to give feedback?If you have questions or encounter issues, post a comment below, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps prioritize future enhancements.  

 Set team or scenario notification options for IMS organizationsIMS organizations can now enable or disable each notification type independently at the team level — the same fine-grained controls previously available only to non‑IMS organizations. Scenario-level notification settings continue to override team settings when present.OverviewTo give teams finer control over the notifications they receive, administrators and team managers in IMS organizations can now choose which situations trigger Fusion notifications. Instead of a single on/off switch for all notifications, you can toggle each notification type independently:Notify on warning — Send a notification when a scenario execution logs a warning. Notify on error — Send a notification when a scenario execution fails. Notify when scenario is disabled — Send a notification when Fusion auto‑deactivates a scenario (for example, after too many consecutive errors).Scenario-level notification settings still take precedence over team-level settings. If a scenario has its own notification configuration, that configuration is applied regardless of the team setting.How to configure team notification options (IMS organizations)Sign in to Workfront Fusion and open the Admin or Team management area for your IMS organization. Select the team you want to configure. Locate the Notifications section for the team (use Show advanced settings if required). Toggle the individual notification types you want the team to receive: Notify on warning, Notify on error, and Notify when scenario is disabled. Save your changes.How to configure scenario-level notification optionsOpen the scenario in the Fusion canvas. Open the scenario settings or the notification panel. Set the desired notification options for that scenario. These settings will override the team-level values for this specific scenario. Save the scenario settings.Behavior and tipsScenario settings always override team settings. The team notification UI indicates when a scenario has an override for a particular notification type. By default, all notification types are enabled. Review team and scenario settings after migration to ensure teams receive the notifications they expect. If your organization uses the Adobe Unified Shell, notifications are delivered through the Adobe Notifications area — check the shell’s notification center for messages. Use team-level controls to set broad defaults (for example, suppress Notify on warning for very noisy teams) and use scenario-level settings for exceptions (for example, enable Notify on error for a mission‑critical scenario). Audit your notification settings periodically to avoid notification fatigue and ensure important events (errors and disabled scenarios) reach the right people.Where to find documentationStep‑by‑step instructions and reference details are available on Experience League: see Set notification options for usage examples and troubleshooting.Need help or want to give feedback?If you have questions, run into issues, or want to suggest improvements (for example, notification digests, more granular recipient controls, or programmatic management of notification defaults), post a comment below, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize future enhancements. 

Restrict webhooks by Adobe IMS authorization and browser originRestrict webhooks by Adobe IMS authorization and browser originWe’ve added two new security controls for custom webhooks: Allowed Origins (CORS) to restrict browser-based calls to specific domains, and Adobe IMS Bearer token validation so webhooks accept requests only when callers present a valid Adobe IMS access token.OverviewCustom webhooks can now enforce two common security requirements:Allowed Origins (CORS) — Specify which browser origins may invoke the webhook from client-side JavaScript. Requests from other origins are blocked by CORS, preventing untrusted web pages from calling your webhook. Adobe IMS authorization — Require requesters to send an Adobe IMS access token in the Authorization header (Bearer <token>). Fusion validates the token before accepting the webhook payload, enabling secure server-to-server or user-scoped calls using Adobe Identity Management.How to configure Allowed Origins and IMS authorizationOpen the Add a hook dialog for the webhook you want to create or edit and check Show advanced settings. Under Authorization type, select Adobe IMS (Bearer token) if you want Fusion to validate incoming IMS tokens. In the Allowed origins field, enter the list of origins (for example https://www.example.com, https://app.example.com) that should be permitted to call the webhook from a browser. Use exact scheme + host (+ port when needed). Save the webhook. When IMS is enabled, Fusion will validate the Authorization header and when Allowed origins are set, Fusion will include the appropriate CORS response headers for allowed browser requests.Tip: Specify only origins you control (including protocol). If you need server-to-server calls from non-browser clients, IMS authorization is the recommended approach—CORS does not apply to server-side requests.Behavior and tipsAllowed Origins implements CORS policy for browser-initiated requests. Non-browser clients (server-to-server) are not subject to CORS; use IMS validation or other auth to secure those calls. When IMS authorization is enabled, send the Adobe IMS access token in the Authorization header as Bearer <access_token>. Fusion validates the token before accepting payloads. If both controls are used together, browser requests must come from an allowed origin and include a valid IMS token to be accepted. Leaving Allowed origins empty results in no browser-origin restriction (default permissive behavior for CORS). Leaving Authorization type unset means Fusion will accept unauthenticated requests (unless other protections are in place). Use descriptive webhook names or notes to indicate which environment (dev, staging, prod) or client application each webhook and policy is intended for.Where to find documentationStep‑by‑step configuration details and examples are available on Experience League: see Webhooks and HTTP module authentication and CORS settings for usage examples and troubleshooting.https://experienceleague.adobe.com/en/docs/workfront-fusion/.../webhooks-updated#use-a-webhook-with-adobe-identity-management-system-imsNeed help or want to give feedback?If you have questions or run into issues, post a comment below, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize future enhancements (for example, allowlist management APIs, automated origin validation, or expanded IMS claim checks). 

 Adobe Express connector now available in Workfront FusionWe’ve added a new Adobe Express connector so you can automate common Express workflows—like listing tagged documents, creating variations, exporting renditions, and checking operation status—directly from Workfront Fusion integrations and automations.OverviewThe Adobe Express connector exposes the primary Express API surface so you can programmatically interact with Express documents and tagged elements from your Fusion scenarios. The connector maps the Express API endpoints into modules that make it easy to include Express operations in integration flows, automation canvases, and scheduled jobs.Connector capabilities (API endpoints)Tagged documents — List all documents that contain tagged elements so you can discover assets to process. Tagged document details — Retrieve metadata and the tagged-element structure for a specific document to inspect editable regions and element IDs. Generate variation — Create new document variations by modifying tagged elements (for example, swap text, replace images, or change colors) and kick off asynchronous generation. Export rendition — Export a document or variation to JPG, PNG, MP4, or PDF renditions for downstream delivery or archival. Status — Check the status of asynchronous operations (such as variation generation or export jobs) so you can poll and take action when processing completes.What you can do with the Adobe Express connectorAutomate batch exports of finalized Express documents to your DAM or cloud storage (PDF, JPG, PNG, MP4). Drive templated content production by generating variations programmatically—populate tagged text, swap tagged images, or apply style changes for personalized outputs. Build end-to-end flows that discover documents, create variations, wait for generation to finish, export renditions, and then notify stakeholders or update records in downstream systems. Integrate Express document workflows with marketing automation, publishing pipelines, or asset management systems using Fusion’s mapping and conditional logic.How to get startedOpen your integration or automation canvas in Workfront Fusion and add the Adobe Express connector. Select the module that corresponds to the Express operation you need (Tagged documents, Tagged document details, Generate variation, Export rendition, or Status). Generate credentials at developer.adobe.com. Configure module inputs—document IDs, tagged element updates (payload), export format and options, and polling intervals for async operations. Map outputs into subsequent steps in your flow (for example, pass exported file URLs to an HTTP module, upload to cloud storage, or notify via email/Slack).Tip: Use the Status module to poll asynchronous jobs (variation generation or exports). Chain the Status check with conditional steps so your flow only proceeds when processing is complete.Behavior and tipsVariation generation and some export operations are asynchronous. Request a job and use the returned job ID with the Status module to determine completion. When updating tagged elements, include the element IDs and the correct edit payload as returned by the Tagged document details call to ensure modifications apply to the intended regions. Exported renditions return downloadable URLs (or files) that you can immediately ingest into other systems or store in Fusion-managed connectors. Saved credentials for Adobe Express are reusable across multiple Adobe connectors and modules—create the credential once and select it wherever Express auth is required.Where to find documentationStep-by-step instructions and reference details are available on Experience League: see the Adobe Express connector docs for module references, payload examples, and troubleshooting tips.Need help or want to give feedback?If you have questions or run into issues, post a comment below, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize enhancements (for example, additional export options, more granular variation controls, or deeper integration with Adobe storage and asset services). 

 Product update:mTLS support for custom webhooksTo meet stronger security requirements, you can now use mutual TLS (mTLS) with custom webhooks. Add a client certificate and private key to a webhook so Experience League integrations and automations authenticate to the receiving service using client-side TLS credentials.OverviewCustom webhooks now support Client certificate authorization. When you configure a webhook to use a client certificate, Fusion will present that certificate and private key during the TLS handshake so the remote service can verify the client. This provides an extra layer of security for server-to-server webhook delivery when the endpoint requires mTLS.How to configure mTLS for a webhookOpen the Add a hook dialog for the webhook you want to create or edit and check Show advanced settings. Under Authorization type, select Client certificate. In the Credentials field, click Add. This opens the Create a key dialog. Give the key a descriptive Key name (for example, “My HTTPS Client Certificate Auth key”). Paste the client Certificate (PEM) into the Certificate field. Use Extract if your certificate is bundled with other data. Paste the corresponding Private key (PEM) into the Private key field. Use Extract if the private key is in the same PEM bundle. Click Create a key to save the credential. Back in the Add a hook dialog, select the new key from the Credentials dropdown and click Save.Tip: Use a descriptive key name to make it easy to identify which certificate is used for which environment (dev, staging, prod).Reuse keys in HTTP modules and other placesThe client certificate keys you create for webhooks are not limited to use with webhooks. The same saved credentials (Basic auth and Client certificate keys) are selectable in HTTP modules (for example, HTTP > Make a request), so you can reuse one saved key for outgoing requests to the same mTLS-protected endpoint. Create the credential once and use it anywhere the matching auth type is supported.Notes and behaviorCredentials (both Basic auth and Client certificate keys) are saved once and can be reused across multiple webhooks and HTTP modules — you don’t need to re-enter them each time. Leaving the Credentials field empty means Fusion will send the received webhook data without presenting a client certificate. The Extract buttons in the Create a key dialog can parse a certificate or private key out of a pasted PEM bundle so you don’t have to split combined files manually. Stored keys are used for authentication during the TLS handshake; they are not sent as part of the webhook payload.How to get help or give feedbackIf you have questions or run into issues when configuring mTLS, post a comment below, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps us prioritize enhancements (for example, additional certificate formats, automated rotation, or private key management integrations).Where to find documentationStep‑by‑step instructions and reference details are available on Experience League: see the Webhooks and HTTP module authentication topics for configuration examples and troubleshooting tips. 

Product update: Workfront Planning v2 connectorWorkfront Planning v2 connector now availableWe’ve released a new connector that exposes the expanded capabilities of the Workfront Planning API version 2 so you can automate and integrate Workfront Planning resources directly from Experience League integrations and workflows.OverviewThe new Workfront Planning v2 connector adds modules that map to the Planning API v2 surface so you can programmatically manage Workfront Planning workspaces, record types, records, fields, and access workflows. The connector also includes user and permission queries and a generic custom-call module so you can call any remaining endpoints not covered by the dedicated modules.What you can do with the Workfront Planning v2 modulesCreate, read, update, and delete workspaces, record types, records, and fields. Retrieve user-level info such as authorization ID and permissions. Request access to a resource and view pending access requests. Make custom API calls to any Workfront Planning v2 endpoint via the generic request module.How to get startedOpen your integration or automation canvas and add the Workfront Planning connector. Select the Workfront Planning v2 modules for the operations you need (Workspace, Record Type, Record, Field, User, Access Requests, or Custom Request). Authenticate with your Workfront Planning credentials and grant the connector the required permissions. Configure the module inputs (IDs, payloads, query parameters) and map outputs into subsequent steps in your flow.Tip: Use the Custom Request module to call any v2 endpoints not yet provided as first-class modules, or to experiment with new API capabilities before we add dedicated actions.Where to find documentationFull reference and step-by-step instructions are available on Experience League: Workfront Planning modules.Need help or want to give feedback?If you have questions or run into issues, post a comment below, start a thread in the Experience League Community, or contact Adobe Support through the Admin Console Support portal. Your feedback helps prioritize new modules and improvements. 

We want to hear how you work with brand standards, legal requirements, product information, competitor insights, and company policies, especially if you're using AI to bring any of this into your workflow today. Your input will directly influence the early concepts our design teams are building. Who we’re looking for✓AEM users who manage, deploy, or create digital assets✓ AEM users who are familiar with how context is managed at their company - this can include legal context, brand standards, product information, competitor insights, or company policies.✓ To participate in pre-release activities, you must be a member of the Adobe Feedback Program. If you aren’t sure whether your company is a member, no worries - we will check when you sign up! What we ask of users✓ Join us for a 30 minute session where we will discuss how you manage context at your company today, whether or not you are using AI as part of this process. Timeline✓ Interviews will take place this week and next week. How to joinCLICK HERE to sign up for a time to chat with the team. We’ll post below once the interview timeslots are full. Questions?Ask below — the research team will be monitoring this thread throughout the sign-up period. 

Product update: View and compare scenario versionsThis post introduces a new Review changes experience that makes it easy to see exactly what changed between two versions of a scenario so you can confidently restore older versions when needed. OverviewYou can now open a side-by-side comparison of any two versions of the same scenario to view detailed differences before you restore a version. The Review changes view highlights additions, removals, and edits (colored green and red) and groups changes by logical sections (Scenario, Scenario settings, Modules, Flows, Router routes, Error handlers, and Orphan groups). Restoring a version creates a new version, so all restores are reversible.How to compare scenario versionsClick Scenarios in the left panel and open the scenario you want to inspect. Click the More icon at the bottom of the screen, then choose Previous Versions. From the list of previous versions, click View changes for the version you want to compare. The Review changes panel opens and shows a side-by-side comparison: the current scenario on the left and the selected version on the right.Tip: Use the Compare from and Compare to dropdowns near the top of the panel to pick any two versions for comparison.Understand the comparison viewThe Review changes panel visually indicates what would happen if you restored the right-hand version:Red (left): Items present in the left (current) version that would be removed if you restored the right-hand version. Green (right): Items present in the right-hand version that would be added if you restored it. If a value changed between versions, you’ll see the old value in red on the left and the new value in green on the right.Change groupsChanges are grouped into these sections to help you quickly locate relevant differences:Scenario: Name, description, and type. Scenario settings: Schedule and processing options. Modules: Modules added, removed, moved, or reconfigured. Flows: Branches added, removed, or reordered. Router routes: Routes and their contents. Error handlers: Error-handling branches. Orphan groups: Disconnected modules on the canvas.Restore behaviorTo revert to the version shown on the right, click Revert to selected version. Restoring saves the restored scenario as a new version so the change itself can be undone later. If you want to restore the version currently shown on the left, click the ⇄ swap button to put it on the right, then click Revert to selected version.When there are no differencesIf the two selected versions are identical, the Review changes view displays No differences found.More information and supportFor step-by-step guidance, see: View and manage scenario versions on Experience League.If you have questions or feedback, post a comment below or contact Adobe Support via the Admin Console Support portal. 

This post is for informational purposes only. It is not legal advice and does not warrant your compliance. The Adobe Marketo Engage product capabilities described in this help article, configured and operated appropriately, support a compliant implementation. Each user is responsible for determining and complying with its obligations under applicable law.OverviewOn April 14, 2026, France’s data protection authority (CNIL) published a recommendation on the use of open tracking pixels in emails. Three days later, Italy’s independent data protection authority (“Garante”) published Provision No. 284 (the “Garante Provision”). Both guidances, while non-legally binding, clarify when consent is required and highlight the importance of proper consent practices for email pixel tracking. These policies could impact sending processes for any entity delivering emails to subscribers who fall under applicable EU privacy law. As regulators continue to clarify guidance on tracking pixels and related issues, Adobe will continue to monitor updates and inform you of changing technical capabilities. Adobe’s documentation on email tracking pixels reflects current regulatory guidance. Adobe will continue to update documentation as needed to reflect relevant changes that may impact use of Marketo Engage as regulatory requirements evolve. Delays in updating materials do not constitute a failure on behalf of Adobe.Marketo Engage offers controls that help you manage open tracking at the email level. Users are responsible for determining their own compliance obligations under applicable CNIL guidance and other laws. What is an email tracking pixelAn email tracking pixel is a small transparent image (just 1x1 pixel in size) embedded in the HTML of an email. When a recipient’s email client loads the email images, the pixel pings a server that records data such as a timestamp, device type, email client, and sometimes an IP address for approximate location. That log is tied to the recipient’s record, allowing marketers to see whether an email is opened.Guidance on consent trackingDetailed steps are outlined for Marketo Engage users in this help article on Experience League.Updates and supportFor the latest updates, bookmark this post. If you have any questions, please post a comment below.

Prior to March 2026, a boolean FALSE value was treated as "no value" during an API merge. This meant that if either of the merged leads had a TRUE value, the result would be TRUE. But in cases when FALSE was an important value, it could cause problems (for example, if a lead's value changed and then merged with an old record, the value could be erroneously reverted back). This behavior was different than other field types.In the March '26 release, Adobe fixed this issue. For API merges, Salesforce merges when they are synced to Marketo, as well as Automerge (if you have it configured); only NULL values in boolean fields are treated as "No Value" when determining which lead to take the value from.The result is that the conflicting field values are now taken from the "winning" record (the resulting lead or contact), unless the winning lead has NULL for that field and the "losing" record (the one disappearing) has a value (TRUE or FALSE). Standard Marketo boolean fields, such as Unsubscribed, will always have a value (TRUE or FALSE), so these will be taken from the winning lead in all cases. 

Hey AJO community! We've just released an updated version of the Image to HTML converter feature, delivering improved accuracy in HTML generation through the use of higher-tier LLM models!This enhancement improves upon the existing feature that enables marketing teams to convert static image-based email designs (JPEG or PNG) into fully modular, editable HTML templates ready for deployment in the Email Designer, without requiring developer involvement. The updated model improves the precision and reliability of the generated HTML output, reducing post-generation corrections and supporting more consistent production workflows.If you're running email through Journey Optimizer and haven't tried this yet, check out the documentation to learn more! Documentation: https://experienceleague.adobe.com/en/docs/journey-optimizer/using/content-management/content-templates/image-to-html  

The Project Falco beta program grants you exclusive access to an updated version of Adobe Journey Optimizer B2B Edition that is specifically designed to supercharge your Marketo Engage instance (no purchase required).Program highlights• Agentic Program & Journey Creation: Design and optimize omni-channel lead journeys inseconds leveraging your existing programs, campaigns, and channels inside Marketo Engage.• Agentic Audience Segmentation: Prompt the audience agent to automatically discover andcreate audience segments using Marketo Engage data.• AI-powered Decisioning: Achieve next-gen personalization through AI-powered Next-bestJourney and Journey Path decisioning.• Omni-channel Orchestration: Connect and activate inbound and outbound channels togetherfrom a single journey canvas, expanding to web and paid channels.• Agentic BDR Experience: Allow your BDR teams to automate outbound sequences using theAccount Qualification Agent together with integrated marketing data.What you getEarly accessFirst access to new capabilities: AI agents, audience creation, journey orchestration, conversational AI, and more, before general availability.Direct product line1:1 engagement with the Development, Product Management, Design, and Product Marketing teams through a dedicated private Slack space and regular conference calls.Roadmap influenceReal influence over what we build next. Participate in the development process, submit enhancement requests prior to release, and directly shape the final feature set before it ships.Marketo-native setupAlready on Marketo Engage? Adobe Journey Optimizer B2B Edition Prime is built to integrate seamlessly, no heavy lift to get started.What’s included in your beta access• Audience Creation and Management• Journey Creation, Optimization, and Decisioning• Conversational AI Experiences• Lead Journeys• Brand Concierge• Sales Qualifier• Reporting & Analytics Project Falco video demoWhat we ask of youDurationThe beta program begins in late June and runs through approximately the beginning of August.Your investmentAll we need is your time and honest feedback. There is no purchase required.After the 6 weeksThe conversation doesn’t have to end there. Beta partners can extend their involvement as the product moves toward general availability.How it works1. Apply. Submit your interest. We’re selecting a small cohort of Marketo Engage customers to partner with.2. Onboard. We get you set up. Because you’re already on Marketo Engage, the integration isstraightforward.3. Use and explore. Your team runs Adobe Journey Optimizer B2B Edition Prime in yourenvironment across the 6-week window.4. Feedback sessions. Regular touchpoints with the Adobe product team. Your input directlyinfluences roadmap decisions.5. Extend or transition. At the end of the beta, we discuss continued involvement in thelighthouse program if you are open to it.Ideal for• Existing Marketo Engage customers• Marketing operations practitioners• Teams with a mandate to evaluate AI in their stack• Organizations willing to co-create with us• Practitioners who want influence, not just accessCommon questionsDo we need to buy anything to participate?No. There is no purchase required to join the beta. Your only investment is time and feedback.We’re already on Marketo. How much setup is involved?Adobe Journey Optimizer B2B Edition Prime is designed to integrate with Marketo Engage data, so the lift to get started is minimal. We handle all of the onboarding.What does “design partnership” mean in practice?It means your team’s experience in the product shapes what we build next. You’ll have multipletouchpoints with the Adobe product team during the Beta Program.What happens after the 6 weeks?There’s an opportunity to extend your involvement beyond the beta. We’ll discuss options based on your team’s goals and our roadmap timing.How many companies are you selecting?We’re keeping the cohort intentionally small, so every partner gets meaningful access and attention from the product team. Ready to co-design what’s next?The beta launches in late June. Spots are limited.