Product Updates

We recently learned about an upcoming Salesforce security requirement that impacts the integration between Salesforce and Adobe Marketo Measure.Salesforce is introducing mandatory Connected App security updates for integrations that use the refresh token authentication flow. To ensure uninterrupted connectivity between Salesforce and Adobe Marketo Measure, you must update your Salesforce Connected App security settings. The current deadline set by Salesforce is November 12, 2026. Please work with your Salesforce admins to ensure these steps are completed as soon as possible. Why this changeMarketo Measure is updating its Salesforce authentication to reduce reliance on long-lived refresh tokens. Short-lived access tokens continue to be used, but new access tokens are obtained through JWT-based authentication instead of refresh-token renewal. This reduces exposure associated with long-lived refresh tokens. Before you beginComplete the Salesforce steps using an account with System Administrator access. Identify the Salesforce integration/sync user used by your Marketo Measure connection.Salesforce continues to display the connected app as Bizible. Menu locations and action labels can vary by Salesforce interface and org configuration. Use Setup's Quick Find to locate the pages named below. Screenshots are examples; names and layout may differ in your org. Steps to follow 1. Install the existing Bizible connected app 1. In Salesforce Setup, search for and open Connected Apps OAuth Usage.2. Locate Bizible and select Install. If it is already installed, continue to section 2.3. Complete any installation prompts. This makes the app's local access policies available for your org to manage; a package installation link or AppExchange URL is not required for this route. If Bizible is not listed or Install is unavailable, contact your Salesforce administrator or Adobe Support before proceeding. Do not create a replacement connected app. 2. Configure the connected app policyOpen the Bizible policy settings using whichever route is available in your org:1. Setup > Manage Connected Apps: select Bizible, then Edit Policies; or select Edit next to Bizible if shown.2. Setup > App Manager: locate Bizible and select Manage from its action menu, then Edit Policies.3. Setup > Connected Apps OAuth Usage: locate the installed Bizible app and select Manage App Policies, if available.These are alternative routes to the same policy settings; use only one. If Manage is not available in App Manager, use Manage Connected Apps or Connected Apps OAuth Usage instead. Update OAuth Policies 1. Under OAuth Policies, set Permitted Users to "Admin approved users are pre-authorized."2. Acknowledge any Salesforce confirmation prompt, then save the changes. Important: Complete the permission-set configuration and user assignment below before attempting JWT authentication. This policy restricts app access to approved users, so account for any other users who require access to this connected app.Other settings visible in the screenshot, including IP restrictions, refresh-token policies and session policies, are examples only. Do not change them solely to match the screenshot. 3. Add Bizible to a permission set1. In Setup, search for and open Permission Sets.2. Open an appropriate permission set already assigned to the Measure integration/sync user. Alternatively, you can also create a dedicated permission set and open it. The easiest way to create a new dedicated permission set is to clone the existing Bizible Administrator Permission Set. 3. Open Assigned Connected Apps, then select Edit.4. Select Bizible under Installed Connected Apps and use Add to move it to Enabled Connected Apps. Select Save.5. Confirm that Bizible appears under Assigned Connected Apps. 4. Assign the permission set to the sync user1. In the permission set, select Manage Assignments > Add Assignments.2. Select the Salesforce integration/sync user used by Marketo Measure, then complete the assignment.If this user already has the permission set, no additional assignment is needed. You can also assign it from Setup > Users > [integration/sync user] > Permission Set Assignments, using Edit Assignments where available. 5. No certificate upload is requiredYou do not need to upload a certificate for this change. The certificate is already configured for the Bizible connected app. 6. Enable JWT in Marketo MeasureAfter completing the Salesforce configuration, enable the JWT authentication feature in Marketo Measure for the Salesforce connection. If the feature is not available, contact Adobe Support for assistance. Note: If you no longer use Measure and Salesforce integration, please uninstall the Bizible app from your Salesforce.  If you encounter any issues or need assistance with this change, contact Adobe Support.

OverviewWe’ve made several focused improvements to the new scenario designer to speed up editing on wide monitors, make it obvious which module or filter you’re working on, and let you search across mappings, module settings, and filters. These changes reduce mouse travel for large canvases, keep your context steady while you edit, and help you quickly find where a value is used.Applies toThese updates apply only to the new scenario designer. To use them, toggle Try the new design in the scenario editor. The classic designer is unchanged.What’s newResizable right‑hand panel — drag the left edge of the right panel to make it wider or narrower; double‑click the edge to reset. The width you set is saved to your user preference so your workspace stays consistent across sessions. Canvas stable while editing — opening a module no longer recenters or shifts the canvas. This keeps your position on large screens and reduces panning and mouse movement while you make edits. Clear edit highlights — the open module (or the open filter’s label) receives a moving dashed outline so you can instantly see what panel you’re editing without the canvas jumping. Filter context in the filter panel — when you open a filter the panel now shows the two modules the filter sits between, displayed by ID and name, so you always know the filter’s placement in the flow. Search across mappings, settings, and filters — the global search now matches mapped values, module settings, and filter conditions in addition to module names and IDs. Each search result indicates where the match was found (for example: mapping → source, mapping → target, filter condition, module setting). New keyboard shortcuts — quick keys to confirm or close panels, navigate to previous/next modules, and run the scenario one time without leaving the keyboard (see Getting started for the list).How it works (quick)Enable the new scenario designer by toggling Try the new design in the upper‑right of the editor if you haven’t already. Open a module or a filter. The canvas will remain fixed and the edited module or filter label will show a moving dashed outline to indicate focus. Resize the right panel by dragging its left edge. Double‑click the edge to reset to the default width. Your chosen width is persisted for your user. Open the filter panel to see the filter’s context — the two modules it connects (ID and name) are shown at the top of the panel. Use the search box (cmd/ctrl + K) to find matches across module names/IDs, mapping sources/targets, module settings, and filter conditions. Each result includes a label describing where the match was found so you can jump directly to the relevant place. Use the keyboard shortcuts (below) to confirm/close panels, move between modules, or run a single execution without the mouse.Keyboard shortcuts (new)Confirm / Close panel — Enter (confirm) / Esc (close) Next module — Ctrl / Cmd + ] Previous module — Ctrl / Cmd + [ Run scenario once — Ctrl / Cmd + RWhy this mattersLess mouse travel: stable canvas and a resizable panel reduce panning and pointer movement on large monitors so you can edit faster. Clear editing context: the dashed outline and filter context show exactly which module or filter you’re editing, lowering the risk of accidental changes. Faster refactors and debugging: searching mapped values, settings, and filter conditions makes it easy to find where a variable or value is used across the scenario. Keyboard‑centric workflows: new shortcuts let power users confirm changes, navigate, and run a scenario without reaching for the mouse.Getting startedOpen a scenario and switch to the new scenario designer with the Try the new design toggle in the editor’s upper‑right. Resize the right panel: drag the left edge to the width you prefer; double‑click the edge to reset. Your chosen width is saved for future sessions. Open a module or filter and notice the canvas stays put while the open item is highlighted with a moving dashed outline. Open the filter panel to see the two modules the filter sits between (ID + name). Press cmd/ctrl + K and search for a mapped value, a filter condition, or a module setting. Click a result to jump to that location; the result label shows where the match was found. Try the keyboard shortcuts above to confirm changes, move between modules, or run the scenario once from the keyboard.Troubleshooting (quick)Toggle not visible: If you don’t see Try the new design, the new designer may not be enabled for your organization — contact your admin or open a support ticket. Panel width not persistent: The width is saved per user and per browser. If it resets, clear browser storage for the Fusion domain and reapply the width, or sign out and in. If issues persist, capture the browser console logs and open a ticket. Search missing results: Search matches exact mapped values, filter conditions, and settings; ensure you’re using the exact token or try partial terms. If a mapping is collapsed, expand the module or mapping list and retry. Keyboard shortcuts not working: Ensure the editor has focus and that your browser or OS hotkeys aren’t conflicting. Try focusing the canvas or right panel and retry. If still blocked, check browser extensions that may intercept key events.Documentation & supportFor full editor details and step‑by‑step guides, see the Experience League scenario editor documentation and keyboard shortcut reference (links available in the product help menu).Feedback and supportTell us how these updates speed up your workflow or suggest improvements (examples: per‑panel width defaults, search filters for result types, configurable highlight styles) by:Posting in the Experience League Community scenario editor thread. Opening a support ticket via the Admin Console Support portal for organization‑specific issues.Try these improvements in the new scenario designer to reduce panning, find mapped values faster, and keep your editing context visible—then let us know what else would speed up your authoring experience. 

OverviewWe’ve added an AI‑powered explanation layer that gives short, plain‑language descriptions of errors and suggested fixes alongside the original error details. Read the raw error and the AI explanation together so troubleshooting is faster and more approachable for everyone on your team. What’s newAI explanations next to errors — concise, human‑readable summaries and recommended actions appear next to the original error message so you see both context and guidance in one place. Where explanations appear — available in three locations: Scenario designer: inside a module’s error details panel. Scenario execution history: on the failed run’s details page; when multiple modules failed you can request an explanation per module. Insights page: in the Failed executions table so triage from Insights is faster. Per‑error granularity — request explanations for individual module errors in a run so you can focus on the most critical failures. Human‑friendly remediation steps — suggestions include likely root causes, next diagnostic commands or checks, and safe first steps to resolve the issue. New‑designer only — the feature is available in the new scenario designer experience to ensure tight integration with the editor’s right panel and Live Trail.How it works (quick)Open a scenario in the new scenario designer and run it (or view a failed run from the execution history). When a module shows an error, open its error details. Click Explain with AI (or the Explain icon) next to the error. The AI returns a short explanation and suggested next steps that display alongside the original error text and timestamps. On the failed run details page you can click Explain for each failed module to get per‑module guidance. From the Insights page, open a failed execution row and request the AI explanation directly from the Failed executions table for quick triage.Why this mattersFaster troubleshooting: get a clear, prioritized description of what likely went wrong and what to try next without translating cryptic logs. Lower cognitive load: non‑engineers and new team members can act on failures faster because recommendations are written in plain language. Targeted remediation: per‑module explanations mean you can address the root cause rather than chasing symptoms across the scenario. Integrated triage: explanations in Insights let operations and SREs begin investigation from high‑level dashboards without repeatedly switching UIs.Getting startedSwitch to the new scenario designer (toggle in the upper‑right of the editor) if you haven’t already. Run a scenario that triggers an error, or open a failed execution from the execution history or Insights → Failed executions table. Click Explain with AI next to the error to generate the explanation. Review the suggestion and apply recommended checks or fixes. Use the explanation to create follow‑up tasks, add context to support tickets, or iterate on scenario design to prevent recurrence.Troubleshooting (quick)No Explain button visible: Ensure you are in the new scenario designer and that your organization has an active AI license. If both are true and the control is still missing, contact your admin or open a support ticket. Explanation seems irrelevant or incorrect: Explanations are diagnostic suggestions based on available error data. Provide more context by expanding the module error details or including Live Trail entries, then retry Explain. If persistent, capture the run and open a support ticket with the executionId and screenshots. Multiple errors in one module: The AI summarizes the visible error context. Expand the raw details (timestamps, request/response) before requesting an explanation for better results. Sensitive data concerns: Explanations are generated from the error and the run metadata shown in the UI. If your organization restricts sending certain data to AI services, review your admin AI/data policies before using the feature.Documentation & supportFor full steps and examples, see the Experience League article: Explain a scenario error with AI.Feedback and supportTell us how AI explanations help your team or suggest improvements (examples: bulk explain for all failed modules in a run, configurable explanation depth, redact sensitive fields) by:Posting in the Experience League Community scenario editor or Insights threads. Opening a support ticket via the Admin Console Support portal for organization‑specific issues.Try Explain with AI to shorten investigation time, reduce guesswork, and empower more team members to triage scenario failures—then tell us what explanation controls you’d like next. 

OverviewThe Insights page has been updated to make it faster and easier to find the information you need. This release adds page customization, a global widget refresh, a first‑time guided tour, improved search matching, dark mode support, tighter access for the Performance widget, and deep links that open Organization Operations pre‑filtered for a scenario and team.What’s newCustomize the page — show or hide widgets and reorder them to surface the metrics that matter most to you. Refresh all widgets — a single control reloads data for every widget on the page while preserving each widget’s filters and state. Search by ID — the Organization Operations and Top Scenarios by Operations widgets now match Scenario and Team on ID as well as name, improving discoverability when names change or duplicates exist. Dark mode — the Insights page and its widgets follow your account or system dark mode setting for a consistent visual experience. Performance widget access — the Performance widget is shown only to users who have Organization Edit permission in the active organization or Organization View permission on the admin page. Open Organization Operations from a scenario — deep links let you open Insights with the Organization Operations widget already filtered to a specific scenario and team for faster triage. Right click on the scenario ID — shows the scenario name and gives an option to open itHow it works (quick)Open the Insights page for your organization from the navigation. Use the Customize control (top‑right) to hide widgets you don’t need or drag to reorder cards on the page. Click Refresh all to reload every widget while keeping their filters intact. On first visit, follow the welcome dialog to take the guided tour; dismiss or replay the tour any time from the help menu. Search Scenario or Team by name or by ID inside Organization Operations and Top Scenarios by Operations — both name and ID are matched. If you have Organization Edit or Organization View (admin) permissions, the Performance widget will appear; otherwise it is hidden to reduce noise and protect access to sensitive metrics. Use scenario‑level links (for example from a scenario detail page) to open Insights with Organization Operations pre‑filtered to that scenario and team for instant context. Getting startedOpen Insights from the organization menu. If it’s your first time, accept the welcome dialog and follow the guided tour. Click the Customize control to hide or show widgets and drag to reorder them. Changes are saved to your user preference. Use the Refresh all button when you want a synchronized data refresh across widgets without changing filters. When searching in Organization Operations or Top Scenarios by Operations, try Scenario or Team IDs if names aren’t returning expected results. If you expect to see the Performance widget but don’t, confirm you have Organization Edit permission in the active org or Organization View permission on the admin page. From a scenario list or detail view, use the provided link to open Insights with Organization Operations filtered to that scenario/team for quick triage.Troubleshooting (quick)Search by ID returns no results: Verify you’re using the exact Scenario or Team ID. IDs are exact matches; names still support partial and fuzzy matching. Performance widget missing: Confirm your permissions — Organization Edit in the active org or Organization View on the Admin page are required. Dark mode not applied: Ensure your account or system dark mode setting is enabled; sign out and back in if the theme doesn’t update immediately.Documentation & supportFor step‑by‑step instructions and screenshots, see the Experience League article: View the Insights dashboard for an organization.Feedback and supportTell us how you’re using the updated Insights page or suggest improvements (examples: saved page layouts, widget permission granularity, scheduled auto‑refresh) by:Posting in the Experience League Community Insights thread. Opening a support ticket via the Admin Console Support portal for organization‑specific issues.Try the updated Insights page to customize your view, quickly refresh data, and navigate from scenarios to organization operations with fewer steps—then let us know what additional controls or widgets you’d like next. 

 OverviewWe’ve expanded Workfront Fusion’s API observability so you can monitor scenario executions in far greater detail from your own tools. The October release adds two new execution endpoints, exposes new monitoring fields on existing endpoints, and removes the requirement to scope execution listings to a single scenario. Use these capabilities to build alerts, aggregate errors, and troubleshoot runs without switching to the Fusion UI.What’s newGet Execution Details — GET /api/v3/logs/{executionId}/details returns a paginated list of an execution’s activity events (messages, warnings, errors, timestamps) so you can replay the timeline that led to a failure. Get Execution Bundles — GET /api/v3/logs/{executionId}/bundles returns module-level input and output bundles for a single execution, ordered by cycle → module → operation. Inspect the exact data each module received and produced. deactivated & deactivationReason — new fields indicate whether an execution deactivated its scenario and explain why, enabling immediate detection of stopped scenarios. errorCode & errorMessage — fields that surface execution failure causes. Both are filterable so you can quickly find specific failure types (for example, TIMEOUT). Organization-wide execution search — List Executions no longer requires scenarioId or dlqId, enabling a single call to monitor all executions across your organization. Module statistics — each item in the modules list now includes package name, module name, and the number of operations performed so you can quickly spot heavy or misbehaving modules.How to monitor executions with the API (quick)List failed executions across your org: GET /api/v3/logs?property=status==3 Find executions that deactivated scenarios: GET /api/v3/logs?property=deactivated==true Filter for a specific error code (example: timeouts): GET /api/v3/logs?property=errorCode==TIMEOUT Inspect the timeline that led to a failure: GET /api/v3/logs/{executionId}/details Examine module inputs and outputs for the execution: GET /api/v3/logs/{executionId}/bundles Why this mattersFaster detection: catch deactivated scenarios immediately and trigger automated remediation or notification flows. Centralized observability: forward execution errors, codes and messages into your existing monitoring, SIEM or incident management systems. Deeper troubleshooting: replay event timelines and inspect exact module bundles so engineers can diagnose root causes without manually stepping through the Fusion UI. Org-level monitoring: one API call can now surface high-level execution trends and failures across all scenarios in your organization.Getting startedReview your API credentials and ensure they have permissions to read logs and executions for the organization you intend to monitor. Use the List Executions endpoint to build dashboards or periodic scans for failures and deactivations. Start with queries like status==3 or deactivated==true. When you spot an execution of interest, call /api/v3/logs/{executionId}/details to get the event timeline and /api/v3/logs/{executionId}/bundles to retrieve module inputs/outputs. Map errorCode, errorMessage, deactivated, and deactivationReason into your alerting rules to reduce mean time to detection and resolution.Troubleshooting tipsMissing fields: If you don’t see the new fields, verify you’re calling the v3 API and that your tenant has the October release features enabled. Large bundle payloads: Execution bundles can be large for high-throughput scenarios. Page results and stream or chunk responses in your consumer to avoid memory issues. Rate limits: If you poll frequently for organization-wide executions, implement backoff and batching to stay within API rate limits. Correlating runs: Use executionId, scenarioId, cycle timestamps, and module names to tie execution data back to your internal tracing or logs for complete incident context.Related October release itemsValidate blueprints before creating scenarios Clone connections between teams Connector/key/hook assets (icons) for custom UIs Incomplete execution management (delete, update blueprint/failing module, retrieve failed bundle) Expanded resource management and new user/team/org endpointsDocumentation & supportSee the full changes in the API changelog and the endpoint reference for request/response examples and pagination details:API changelog (Experience League) API reference (Experience League)Feedback and supportTell us how you’re using the new execution monitoring endpoints or suggest improvements (examples: webhook notifications for deactivations, richer error classification, Compact bundle diffs) by:Posting in the Experience League Community API thread. Opening a support ticket via the Admin Console Support portal for account- or configuration-specific questions.Start integrating execution details into your monitoring workflows today to reduce investigation time and improve operational visibility across your Fusion organization. 

OverviewThe Adobe CX Coworker connector for Workfront Fusion lets you call Adobe CX Enterprise Coworker from an automation scenario. Instead of building API calls and parsing JSON yourself, send a plain‑language prompt and let Coworker interpret the request, run the applicable skills, and return a conversational result you can use later in the flow.The connector provides two modules:Run a Prompt — Starts a new Coworker request. By default this module waits for Coworker to finish and returns the result, including both the natural‑language summary and any structured outputs the skill produced. Get Execution Status — Polls an earlier request to check progress or retrieve a result if you started the prompt asynchronously. Use this when you want non‑blocking execution or to coordinate long‑running checks across systems.ImpactThe Coworker connector dramatically reduces the complexity of integrating AI‑driven insights and data validation into automation scenarios. Use cases include:Automatically validating data (for example, dataset quality checks) and routing results to the right teams. Comparing analytics systems (AA vs CJA) and creating tickets or notifications when variance thresholds are exceeded. Generating plain‑language summaries of diagnostics, then creating follow‑up tasks or notifications based on recommendations. Embedding Coworker checks inside onboarding, QA, or deployment workflows so non‑engineers can trigger sophisticated validations without writing queries.Because Coworker can use the account’s available tools and skills, the connector lets scenarios call domain‑aware capabilities (data validation, upgrade validation, insights) while keeping the scenario logic simple.Tryable (quick start)Create a new automation scenario in Workfront Fusion / Adobe Automation and add the Adobe CX Coworker app. Use the Run a Prompt module. In the prompt text box, write a clear instruction such as: Validate the dataset Electronics Sample 1000 and return a summary of any fields with high null rates or obvious invalid values. Run the module and inspect the output. You’ll typically get a conversational summary plus structured fields (quality scores, top invalid values, suggested next steps). If you prefer asynchronous execution, set the Run a Prompt module to return immediately (where supported) and capture the executionId from the module output. Add the Get Execution Status module downstream and pass the executionId to poll for completion. When status is finished, read the result and branch your scenario (create a ticket, send an email, or update records) based on the returned insights.SetupMake sure your Adobe org has access to Adobe CX Enterprise Coworker and that the account credentials used in Automation have the necessary permissions. In Workfront Fusion add and authorize the Adobe CX Coworker connector following the standard app provisioning flow. Decide whether your scenarios should be synchronous (wait for results) or asynchronous (poll for status) and design the flow accordingly. Familiarize yourself with the Coworker skills available to your account (Data Validation, AA→CJA validation, insights, etc.) so prompts are aligned with capabilities. See the official connector docs for up‑to‑date module reference: Adobe CX Coworker modules.Best practices & lessons learnedWrite prompts that are explicit and start with the object name when applicable (for example, “Validate the dataset Electronics Sample 1000” rather than just “Validate Electronics Sample 1000”). That helps Coworker reliably identify resources. For dataset or data checks remember Coworker typically analyzes a recent sample (for example, the last ~1,000 rows). Use follow‑up prompts or additional queries for exhaustive checks where needed. Use structured outputs (executionId, result JSON) from the connector to drive deterministic branching in scenarios rather than parsing free text alone. If you need long‑running validations, prefer the asynchronous pattern: submit with Run a Prompt, store executionId, then poll with Get Execution Status. This avoids timeouts and keeps scenarios resilient. Validate and human‑review suggested actions before making destructive changes. Coworker’s recommendations are a guide and sometimes require business context or further verification. Log prompts and results in your automation audit trail so you can iterate on prompts and improve consistency over time.Common example flowsData quality alert: New dataset ingestion triggers a flow → Run a Prompt to validate key fields → If Coworker flags critical issues, create a high‑priority ticket and notify the data owners. Analytics upgrade check: Scheduled job triggers an AA→CJA comparison prompt → Run a Prompt to validate report suite vs data view → If matching rate is below threshold, generate a diagnostics report and assign remediation tasks. Automated summary & action: After a nightly job, Run a Prompt to summarize anomalies across multiple systems → Use Get Execution Status to wait for completion → Post summary to a Slack channel and create follow‑up tasks for items marked critical.Troubleshooting tipsIf prompts return unexpected results, rephrase the request to be more explicit and include exact resource names or IDs. Confirm the Coworker account has access to the datasets, report suites, or data views you reference; missing access is a common cause of failures. Monitor connector rate limits and design backoff/retry logic for high‑volume scenarios.Further readingFull module reference and implementation details are available in the Workfront Fusion (Adobe Automation) docs: Adobe CX Coworker modules.Got a connector pattern you want to share? Post your scenario in the Experience League Community forums to help others automate with Coworker.

OverviewThe new Scenario editor experience gives you a faster, more focused way to build, navigate, and debug scenarios. The underlying scenario behavior—mappings, filters, schedules, connections, routers, error handlers, and execution—remains unchanged when you switch experiences. You can toggle back to the classic editor at any time. If you don’t see the toggle, the new experience may not yet be enabled for your organization. What’s newModule cards — compact cards show app icon, module name, short description, and module ID with curved links and status indicators for clearer canvas readability. Improved navigation — Compact view, zoom, Focus mode, and a minimap make it easier to move around and reason about large scenarios. Use cmd/ctrl + K for fast search. You can navigate between executions with a single click. Foldable routers — Collapse a router to hide its routes and reduce visual noise while you work on other parts of the scenario. Dark mode — Editor color theme for low‑light workflows and longer sessions. Search‑first module browser — Quickly find modules by name or function and add them to the canvas. Edit history — Undo, Redo, and Undo all let you recover or reset recent changes faster. Unified right panel — A single right‑hand panel now hosts Module setup, Find & replace, Snippets, Live Trail, and request/response details for a consistent authoring experience. Live Trail — see a run as it happens: chronological requests, statuses, and searchable request/response details in one place. Find & replace — replace mapped variables, remap sources, or copy connections across a whole scenario or a single module with a preview of affected modules before you apply changes. Snippets — save selected modules as reusable snippets; search, tag, pin, import/export, and share them with teammates or across your org. Temporary debug logs — enable short‑lived capture of request/response details for limited windows (next hour, day, run, or up to 10 runs) to avoid persistent log storage. Developer Tools — built into the editor: Get app metadata, Copy mapping, Copy filter, Copy module name, Swap connection, Swap variable, and Remap source accessible from module/link context menus or the Find & replace panel.How it works (quick)Open a scenario and toggle Try the new design in the upper‑right of the editor to switch to the new experience (choice is saved per user). Use the search‑first module browser to add modules; module cards display key metadata and status at a glance. Navigate large scenarios with Compact view, zoom, Focus, and the minimap. Fold routers to reduce clutter. Open the right panel to configure a module, run Find & replace, manage Snippets, view Live Trail, or inspect request/response details. Turn on Temporary debug logs in Scenario settings when you need request/response capture for a limited time. Use built‑in Developer Tools from a module or link context menu for rapid debugging and refactoring tasks.Why this mattersFaster authoring and debugging — clearer module cards, focused navigation, and the single right panel reduce context switching so you can build scenarios more quickly. Better observability — Live Trail and temporary debug logs give you targeted visibility into runs without retaining full logs indefinitely. Safe, large‑scale edits — Find & replace previews and Developer Tools let you refactor mappings, sources, and connections confidently across an entire scenario. Reusable work — Snippets let teams standardize and share common scenario sections to accelerate onboarding and maintain consistency.Getting startedOpen a scenario and click the Try the new design toggle in the upper‑right of the editor. Your selection is saved for your user. If the toggle is not present, check with your admin about availability. Explore the module browser and add a few modules; note the module card metadata and status indicators. Use Compact view, zoom, Focus, and the minimap to position and tidy large scenarios. Fold routers to reduce visual noise. Open the right panel to set up modules, run Find & replace, create or paste Snippets, and inspect Live Trail entries during a run. Enable Temporary debug logs from Scenario settings when you need to capture request/response details for a limited timeframe. Try Developer Tools from a module or link context menu for common refactor/debug tasks (for example, Swap connection or Copy mapping).Troubleshooting (quick)No toggle visible: The new experience may not be enabled for your organization yet—contact your admin or open a support ticket. Right panel not showing expected tools: Ensure you’re in the new scenario editor experience (Try the new design enabled). The single right panel consolidates setup, Find & replace, Snippets, Live Trail, and request/response details. Live Trail entries missing request/response: Live Trail shows runtime activity for runs; if you need full request/response capture, enable Temporary debug logs in scenario settings before running. Find & replace affected more modules than expected: Review the preview before applying changes. Use scoped replace (single module) if you only intend to change one area. Snippets import/export issues: Check snippet file format and permissions. If sharing across organizations, ensure recipients have compatible connector access and permissions.Documentation & supportSee the Experience League for full editor details and step‑by‑step guides:The scenario editor (Experience League) Use Live Trail to review a scenario run Find and replace variables, sources, and connections Save and reuse scenario sections with snippets Configure scenario settings (Temporary debug logs)Feedback and supportTell us what you think or request enhancements (examples: per‑route folding defaults, persistent debug retention policies, snippet permission controls, or additional Developer Tools) by:Posting in the Experience League Community scenario editor thread. Opening a support ticket via the Admin Console Support portal for configuration or availability questions. When reporting issues, include the scenario name, example screenshots or screen recordings, and the user toggle state (new vs classic) to help us reproduce and resolve problems faster.Try the new scenario editor to speed up authoring, reduce visual clutter, and get richer, targeted debugging—then let us know what editor improvements you’d like next. 

OverviewThe new Adobe Fusion MCP connector lets you send a plain‑English prompt from a Fusion scenario to the hosted Adobe Fusion Model Context Protocol (MCP) server. An LLM interprets your request, invokes the Fusion tools required to fulfill it, and returns the result plus execution metadata.What’s newSingle‑prompt MCP integration — send one natural‑language instruction to the hosted Fusion MCP server directly from a scenario module. Optional BYO LLM — use Adobe Managed AI by default, or supply an LLM key (OpenAI, Anthropic, Amazon Bedrock) and model if you prefer a different provider. Tool restrictions — restrict which read‑only and write/delete Fusion tools the MCP model may call to enforce least privilege for unattended runs. Audit and summary outputs — the module returns a Response, an Audit Trail of tool calls and results, and a Summary (counts and final status) for transparency and downstream logic.How it works (quick)Add the Adobe Fusion MCP module to your scenario. Create a connection inside the module (click Add → choose Environment and Type → complete Adobe sign‑in/consent). Enter your plain‑English prompt in the module. Optionally choose or add an LLM key if not using Adobe Managed AI. Optionally select Read‑only and/or Write/delete tools to limit what the MCP model may call. Run the module. The hosted MCP model executes the allowed tool calls and returns Response, Audit Trail, and Summary outputs you can map to later modules.Why this mattersFaster, conversational automation — non‑technical users can describe outcomes in plain language and let the model orchestrate Fusion tools. Safe unattended runs — tool restriction fields let you prevent unwanted write/delete operations in automated scenarios. Transparency — Audit Trail and Summary make it easy to review what the model did and to troubleshoot or audit runs.Getting startedEdit a scenario and add the Adobe Fusion MCP module. Create and authorize a connection via the module’s Connection → Add flow. Compose a clear prompt; start with read‑only requests to validate behavior. If desired, add an LLM key to route prompts to OpenAI, Anthropic, or Bedrock instead of Adobe Managed AI. Restrict tools where required, run the module, and inspect Response, Audit Trail, and Summary.Troubleshooting (quick)Connection issues: Ensure the Adobe sign‑in/consent completed and redirects are allowed by your browser/network. Unexpected answers: Clarify the prompt, include constraints or examples, and review the Audit Trail to see which tools produced the output. Tool blocked: Confirm the required tool is selected in Read‑only or Write/delete lists; otherwise the MCP server will not call it. Custom LLM errors: Verify provider key, model name, and that the provider endpoint is reachable and has quota.Output fieldsResponse — the model’s returned text. Audit Trail — record of tool calls, arguments, results, and timings. Summary — totals for the session and final status for quick checks or conditional logic.Documentation & supportSee the Experience League for full module details and configuration steps: Adobe Fusion MCP module (Experience League). For help or feedback, post in the Experience League Community or open a support ticket via the Admin Console Support portal.Try the Adobe Fusion MCP connector to add natural‑language orchestration to your Fusion scenarios — and let us know what prompt controls or safety features you’d like next.

 OverviewTo reduce reliance on long‑lived secrets and make connections more secure and manageable, we’ve added federated connection support to the AWS S3, Azure DevOps, and SharePoint connectors in Fusion. You can now authenticate these connectors using your organization’s identity provider (Azure AD / Microsoft Entra ID or AWS IAM federation) so Fusion obtains short‑lived credentials at runtime instead of storing client secrets or static keys.What’s newFederated connection option — a new connection type for AWS S3, Azure DevOps, and SharePoint that uses your identity provider to mint temporary credentials or tokens. Consistent auth model — setup follows the same federated/OIDC or IAM role pattern you already use for other Azure AD or AWS identity integrations. No long‑lived secrets — Fusion uses short‑lived tokens/credentials returned by your IdP or AWS STS, reducing secret sprawl and rotation overhead. Admin controls — organizations can enforce which identity providers and roles are available, and limit connector permissions through standard Azure/AWS role and scope management.How it worksIn Fusion, go to Connections > Create Connection and choose AWS S3, Azure DevOps, or SharePoint. Select the new Federated / Identity Provider authentication option instead of the client‑secret / token option. Follow the connector’s guided steps to register or select the IdP/client, configure redirect/callback URLs (if required), and map the identity to the target role (AWS role, Azure app role, SharePoint service principal) that grants the needed permissions. Save the connection. At runtime Fusion exchanges an IdP assertion (or assumes an IAM role) and receives short‑lived credentials/tokens which it uses for API calls.Why this mattersImproved security — temporary credentials reduce the window of exposure if a credential is compromised. Easier governance — use existing IdP and role/scopes to manage access, audits, and lifecycle instead of managing connector secrets separately. Consistent admin experience — the federated option follows patterns already used for Azure AD / AWS integrations, lowering setup friction across connectors.How to get startedDecide which identity provider flow your organization will use: AWS: configure an IAM role with a trust policy for your IdP and enable STS assume‑role or OIDC federation. Azure/SharePoint/Azure DevOps: register an app in Azure AD / Microsoft Entra and grant the required API permissions and roles. In Fusion: Connections > Create Connection > choose AWS S3, Azure DevOps, or SharePoint and select the Federated authentication option. Provide the IdP metadata, role/client identifiers, and callback/redirect URL if prompted. Save and test the connection by performing a read action (list buckets, list repos, list sites) to validate permissions. Work with your security/identity team to lock down which roles and scopes connectors may assume for least privilege.Permissions and securityFederated connections act with the permissions granted to the mapped role or service principal — they cannot exceed those rights. No long‑lived client secrets or static keys are stored in Fusion for these connections; Fusion stores only the connection metadata and uses short‑lived credentials at runtime. Follow your org’s policies for registering apps, consent, and role assignment. Consider automated role review and rotation policies on the IdP side.Troubleshooting (quick)Unable to assume role / token exchange fails: Verify the IdP trust relationship / app registration, callback URLs, and that the role/client identifier in the Fusion connection matches the IdP/AWS configuration. Permission errors on actions: Confirm the mapped role or app has the required permissions in AWS, Azure DevOps, or SharePoint. Test with the minimal read action first. Unexpected token expiry: Check your IdP and AWS STS configuration for token TTL and clock skew; ensure Fusion’s runtime calls occur within the token lifetime.DocumentationAWS S3 modules Azure DevOps modules SharePoint modulesFeedback and supportTell us how federated connections are working for your organization or request enhancements (examples: built‑in role templates, automated IdP setup snippets, or delegated admin approval flows) by:Posting in the Experience League Community thread for the respective connector. Opening a support ticket via the Admin Console Support portal for access or configuration help. When reporting issues, include the connector type, IdP flow used, example error messages, and the role/app identifiers to help us reproduce and resolve problems faster.We’re pleased to offer federated authentication across AWS S3, Azure DevOps, and SharePoint — try the new federated connection option to reduce secret sprawl and align Fusion connections with your identity governance practices. 

 OverviewYou can now connect Workfront Fusion directly to the Adobe Marketo Engage MCP server using the new Adobe Marketo Engage MCP connector. The connector exposes an instruction‑driven module that lets you provide open‑ended, plain‑English instructions; an AI agent then determines and executes the Marketo actions required to fulfill your request.What’s newAdobe Marketo Engage MCP connector — a new connector that talks to the Marketo MCP server and exposes Marketo tools to MCP‑compatible agents. Instruction module — enter free‑form, plain‑English instructions (for example, “Create a nurturing program for new trial users in EMEA and add a 3‑step email sequence”) and let the agent translate them into concrete Marketo operations. Action restrictions — admins can explicitly limit which read, write, and delete actions the agent is allowed to perform so unattended runs remain within the approvals you set. AI provider flexibility — by default the module uses Adobe’s managed AI service; you can optionally provide your own OpenAI, Anthropic Claude, or Amazon Bedrock key if you prefer to route requests to another model provider. Tooling parity — Marketo operations exposed through the MCP connector follow the same permission model and tool labeling (Read/Write) as other Fusion MCP connectors.How it worksCreate a Marketo connection: In Fusion, go to Connections > Create Connection and choose Adobe Marketo Engage MCP. Provide organization and authentication details for your Marketo MCP server. Add the Adobe Marketo Engage MCP module to a scenario or use it via an MCP agent (Coworker, custom MCP client). Enter a plain‑English instruction describing the Marketo task you want performed (for example, “Export all leads created in the last 7 days with UTM source=paid_search”). Optionally set an action policy that restricts which Marketo read/write/delete operations the agent can invoke. Choose the AI provider: use Adobe’s managed AI by default, or supply your own OpenAI / Anthropic / Bedrock API key to run instructions against your preferred model. The agent analyzes the instruction, maps it to one or more Marketo API operations, and executes them with the permissions you granted. The module returns an execution summary and any output (export files, created assets, logs).Why this mattersFaster, conversational automation — non‑technical users can drive Marketo actions with natural language without building complex scenarios or custom scripting. Safe unattended runs — action restrictions let you run unattended automations while limiting the agent to only the operations you approve, reducing risk. Flexible AI choice — teams can use Adobe’s managed AI for a turnkey experience or bring their own model keys for governance, latency, or cost reasons. Integration consistency — the connector follows Fusion’s MCP tool and permission patterns so it fits into existing admin and security workflows.How to get startedOpen Fusion > Connections > Create Connection > select Adobe Marketo Engage MCP. Configure connection details for your Marketo MCP server and save. Add the Marketo MCP module to a scenario or open Coworker / another MCP client and connect to your Fusion organization. Compose a plain‑English instruction and run it. Start with read‑only queries (for example, “List programs in the Marketing folder created in the last 30 days”) to verify behavior. Set action restrictions in the connector or scenario if you plan to allow write or delete operations. Test with a small, non‑destructive instruction before scaling up. If you want to use a non‑Adobe model, provide your OpenAI, Anthropic Claude, or Amazon Bedrock key in the module settings and save.Troubleshooting (quick)Connection failures: Verify the MCP server URL, OAuth/client credentials, and that your Marketo organization allows MCP access. Check network reachability and firewall rules. Agent won’t perform an action: Confirm the requested action is included in the allowed actions list. If an operation is blocked, the module returns a clear denial and execution summary. Unexpected or incorrect output: Review the instruction for ambiguity. Try a more specific prompt (step‑by‑step or enumerated requirements) and re‑run. Include example data where applicable. AI provider errors: If using a custom model key, confirm the key is valid, has remaining quota, and the provider endpoint is reachable. Check provider error messages returned by the module for guidance. Large or long‑running jobs: For exports or bulk updates, prefer scenario‑driven runs with explicit retry/timeouts configured; monitor execution logs for progress and partial outputs.DocumentationSee the Experience League reference for details and configuration steps: Adobe Marketo Engage MCP module (Experience League)Feedback and supportTell us how you’re using the Marketo MCP connector or request enhancements (examples: richer prompt templates, per‑action approval workflows, built‑in audit summaries, or automated rollback hooks) by:Posting in the Experience League Community thread for Marketo or the Fusion MCP connectors. Opening a support ticket via the Admin Console Support portal if you encounter unexpected behavior or need migration help. Including example instructions, expected vs actual results, and connection metadata when reporting issues to help us reproduce and diagnose problems faster.We’re excited to bring conversational, policy‑controlled Marketo automation to Fusion. Try the new Adobe Marketo Engage MCP connector and let us know what prompts and controls you’d like next. 

OverviewWe’ve added a new HTTP module: HTTP > Make a JWT request. This module mirrors the behavior of the existing HTTP > Make a request module but builds, signs, and injects a short‑lived JSON Web Token (JWT) based on the claims you provide. By default the signed JWT is sent as an Authorization: Bearer <jwt> header so you can call APIs that require signed JWT authentication without a separate token‑generation step in your scenario.What’s newMake a JWT request module — a new HTTP module that creates, signs, and attaches a JWT to the outgoing request. Claims input — provide standard and custom claims (iss, sub, aud, exp, nbf, jti, and custom claims) in the module UI. Automatic signing — the module signs the JWT with the key material you supply and inserts it into the request (default: Authorization Bearer). Request parity — supports the same HTTP method, headers, body, query, timeout, and retry controls you already use in the HTTP Make a request module.How it worksOpen your scenario and add HTTP > Make a JWT request where you need a signed JWT. Enter the request details as you would in the normal HTTP module (method, URL, headers, body, timeout, retries). In the JWT section, provide claims (for example iss, sub, aud, and exp) and any custom claims required by the API. Upload or paste the signing key/secret and select the signing algorithm your target service expects. The module generates and signs the JWT at execution time and injects it into the request (by default as Authorization: Bearer <jwt>). The HTTP call is executed with the signed token included; response handling and retries follow your configured module settings.Why this mattersSimpler scenarios — remove the extra steps and modules previously required to create and store short‑lived JWTs. Faster integration — authenticate to JWT‑based APIs directly within the HTTP module, reducing scenario complexity. Reduced secrets surface — signing keys are provided per module and not stored as separate tokens in your scenario flow (subject to your organization’s secret management policies).How to get startedEdit your scenario and replace or add HTTP > Make a JWT request where JWT auth is required. Fill in the HTTP request fields (method, URL, headers, body, timeout, Retry Count). In the JWT settings: Enter the claims required by your API (iss, sub, aud, exp, etc.). Supply the signing key/secret and choose the signing algorithm. Optionally change how the JWT is included (default: Authorization Bearer). If supported, you can place the token in a custom header or in the request body per API requirements. Save and test the module by triggering the scenario and verifying the target API accepts the signed JWT.Troubleshooting (quick)Authentication failures: Confirm the claims (iss, aud, sub) and signing algorithm match the API’s expectations and that the signing key is valid. Token expiry: Ensure exp is set appropriately and synchronized with the API’s clock skew tolerance. Unexpected header placement: By default the module uses Authorization: Bearer. If the API expects the JWT elsewhere, set the module to place the token in the required header or body field. Retries and timeouts: The module follows configured Timeout and Retry Count values; remember signed tokens are generated per attempt and any long retry/backoff strategy affects total execution time.DocumentationHTTP > Make a JWT request module (Experience League)Feedback and supportTell us how you’re using the Make a JWT request module or request enhancements (examples: support for key rotation hooks, built‑in JWK retrieval, per‑claim templates, or automatic time skew handling) by:Posting in the Experience League Community thread for the HTTP connector/module. Opening a support ticket via the Admin Console Support portal if you encounter unexpected behavior. Including example requests, the API’s JWT expectations, and scenario metadata when reporting connector issues to help us diagnose problems faster.We hope this makes it easier to integrate with APIs that require signed JWTs. Try the new HTTP > Make a JWT request module and let us know what additional JWT controls you’d like to see next. 

 OverviewWe’ve added a new field to the HTTP modules: Additional Retry Status Codes. This lets you list extra HTTP response codes that should be treated as retryable connection errors when Evaluate all states as errors (except 2xx and 3xx) is enabled. Previously Fusion retried only the built‑in retryable statuses (408, 429 and all 5xx). Now you can extend retry behavior to other status codes (for example, 422 or 404) when your integration needs it.What’s newAdditional Retry Status Codes — a free‑form field on the HTTP Make request module where you can add numeric HTTP status codes (comma or space separated) that should be treated as retryable. When Evaluate all states as errors (except 2xx and 3xx) is enabled, any code listed here is reclassified as a retryable connection error and will be retried according to the module’s Retry Count. Default retryable statuses (408, 429, and all 5xx) remain unchanged and continue to be retried even if this field is empty.How it worksEnable Evaluate all states as errors (except 2xx and 3xx) in the HTTP Make request module. Enter additional numeric status codes (for example, 422, 404) into Additional Retry Status Codes. If the HTTP response matches a listed code, it’s treated like a connection‑type failure and the module will retry the request up to the configured Retry Count. Timeout still controls the maximum wait for each attempt; it does not control pauses between retries.Why this mattersGreater control — Handle transient or upstream validation responses that you want to treat as recoverable without building extra scenario logic. Simpler error handling — Reduce manual branching or custom retry loops in your scenarios by leveraging the module’s built‑in retry engine. Consistent behavior — Treat non‑standard retryable responses in the same way as 408/429/5xx, making integrations more resilient to intermittent backend issues.Important behaviorThis setting has effect only when Evaluate all states as errors (except 2xx and 3xx) is enabled. Codes not listed in the field keep their default behavior. Built‑in retry behavior for 408, 429, and 5xx is unchanged and does not require adding them to this field. If you add a normally terminal status (for example, 404 or 422), it will become retryable — so add codes deliberately. Timeout controls how long each attempt may wait; it does not define a pause or backoff between retries. Configure retry count and timeout accordingly for your use case.ExampleEnable Evaluate all states as errors, set Retry Count to 4, and add 422 to Additional Retry Status Codes. An HTTP 422 response will now be treated as a retryable connection error and retried up to four times like other connection failures.How to get startedEdit the HTTP Make request module in your scenario. Turn on Evaluate all states as errors (except 2xx and 3xx). Locate Additional Retry Status Codes and enter numeric codes separated by commas or spaces (for example: 422, 404). Set Retry Count and Timeout to match your retry and wait expectations. Save and test your scenario to confirm the module retries when the specified status codes are returned.Troubleshooting (quick)Retries not happening: Confirm Evaluate all states as errors is enabled and that the response status exactly matches a code you added (no text or range expressions). Unintended retries: If you see retries for a code you didn’t expect, remove it from Additional Retry Status Codes. Remember adding terminal codes like 404 will make them retryable. Longer total execution time: Each retry attempt can take up to the configured Timeout. Multiply Timeout × (Retry Count + 1) to estimate worst‑case request duration.DocumentationFull module reference and examples are available on Experience League: Experience League - Fusion HTTP module Feedback and supportTell us how you’re using Additional Retry Status Codes or request enhancements (for example, support for status ranges, exponential backoff settings, or per‑code backoff) by:Posting in the Experience League Community thread for the HTTP connector/module. Opening a support ticket via the Admin Console Support portal if you encounter unexpected behavior. Including example requests, response status codes, and scenario metadata when reporting connector issues to help us diagnose problems faster.We hope this gives you more flexible, resilient HTTP integrations. Try the new field and let us know what additional retry controls you’d like to see next. 

OverviewWe’ve added service‑account authentication options to the Jira Software connector in Fusion. You can now create Jira connections using a service account API token or service account OAuth 2. These options let teams build reliable, machine‑level integrations that aren’t tied to an individual user account.What’s newService account — API token: Authenticate the Jira connector with a service account identity using an API token. Service account — OAuth 2: Authenticate via OAuth 2 using a registered OAuth client tied to a Jira service account. Both connection types appear alongside existing user‑based connection options in the Jira connector dialog.Why this mattersStability — Service accounts reduce disruptions caused by employee changes or credential expirations. Auditability — Activities generated by connector operations are scoped to a dedicated service identity, making logging and compliance easier. Enterprise fit — Supports machine‑to‑machine integration patterns and centralized credential governance common in larger organizations.How to get startedOpen Fusion → Connections > Create Connection → choose Jira Software. From the Connection Type dropdown select either: Service account — API token and enter the service account identifier and API token. Service account — OAuth 2 and follow the OAuth client flow (you may need to register an OAuth app in Atlassian and provide client ID/secret and callback URL). Save the connection and run test actions (create issue, update issue, search) to validate permissions.Permissions and securityService account connections act with the permissions assigned to the service account in Jira — they cannot exceed those rights. When using OAuth 2, grant only the scopes required for your scenarios. Secrets (API tokens, client secrets) are stored securely and are not exposed in Fusion UI readouts; only connection metadata and status are visible.Admin checklistCreate a dedicated Jira service account and grant the minimum required project/issue permissions. Decide between API token (simple server‑to‑server) and OAuth 2 (centralized app governance and finer scope control) based on your security policy.Troubleshooting (quick)Actions return permission errors: Review the service account’s Jira project roles and issue permissions and adjust as needed.Where to find documentationJira Software connector — Fusion reference (Experience League) Atlassian: Understand service accountsFeedback and supportIf you have questions, encounter issues, or want enhancements (for example, automated token rotation hooks or role‑based connection templates), please:Post in the Experience League Community thread for the Jira connector Open a support ticket via the Admin Console Support portal for access or migration help Include connection metadata and example error messages when reporting connector errors to help us troubleshoot fasterWe’re excited to deliver more robust authentication choices for Jira integrations. Try the new service‑account connection types and tell us how they work for your automations. 

  OverviewToday we’ve turned on the Fusion MCP server and integrated Fusion with Adobe Coworker. That means you can now interact with your Fusion organization — scenarios, executions, connections, webhooks, data stores, activity logs, and more — via natural‑language in Coworker or any MCP‑compatible agentic platform that supports remote (Streamable HTTP) MCP servers with OAuth.What’s newFusion MCP server is available at https://mcp.fusion.adobe.com/mcp for custom MCP integrations (Claude, ChatGPT, Copilot, Gemini, Cursor, VS Code, and others). Adobe Coworker now includes built‑in Fusion support (standalone Coworker and Coworker in the Fusion right rail). No custom MCP URL or OAuth app registration required for Coworker. All MCP tools described in the Fusion MCP tools reference are exposed to connected agents and follow the same read/write permissions as your Fusion role and team membership.How to get startedChoose the surface you want to use:Coworker (recommended) — Open Coworker (standalone) or the Coworker panel in the Fusion right rail and ask Fusion‑related questions. Coworker uses your Adobe ID and Fusion permissions automatically. To test Coworker integrations: Customization > Integrations > find fusion-mcp > Test. Claude — Add Fusion as a custom connector and point it at https://mcp.fusion.adobe.com/mcp. (Claude Team/Enterprise owners can add custom connectors.) ChatGPT / other MCP clients — Add a custom MCP server of type Streamable HTTP and use https://mcp.fusion.adobe.com/mcp. Authenticate via OAuth when prompted. Custom agents — Connect directly to the MCP server URL from your MCP‑compatible agent implementation.Permissions and safetyThe agent performs actions using your Adobe ID and your Fusion role/team permissions — it cannot access anything you don’t already have permission to view or change. Tools are labeled Read or Write; destructive operations always require explicit confirmation. Connection and key tools return metadata only (name, type, scopes, expiration). They do not expose secret values or credentials.Admin checklistEnsure users and organizations are signed in with Adobe IDs (IMS). Enable MCP access for organizations that want agent integrations. Review and set Read vs Write MCP tool permissions for your teams. Confirm connected app callback URLs if you add custom OAuth apps for non‑Coworker integrations.Troubleshooting (quick)No data visible? — Ask the agent to list organizations and switch to the correct organization (tools: fusion_orgs_list, fusion_orgs_set). Where to find documentationSee Experience League for full Salesforce module reference and connection field details:Configure the Adobe Workfront Fusion MCP server Adobe Workfront Fusion MCP server tools Feedback and supportIf you have questions, find an issue, or want to request enhancements (for example, tailored tone templates for Coworker, additional safety confirmations, or org‑level presets), please:Send feedback straight from your AI assistant with the fusion_feedback_submit tool. Ask it to report a bug, flag a wrong result, request a feature or share praise (for example, "Send feedback to the Fusion team: the scenario list is missing folder names"). Post in the Experience League Community thread for Fusion MCP/Coworker. Open a support ticket via the Admin Console Support portal for migration or access issues.We’re excited to make Fusion accessible via conversational, agentic workflows. Try Coworker or add the MCP server to your preferred agent and let us know how it goes. 

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.