Build better products with our product team
Description - When adding data to a dataflow, on tha Select Data Step, when we Uploade a Json that is bigger than what the first seen screen can hold, there is no scroll bar to look/verify the rest of the json. Why is this feature important to you - Because it supposed to be there, is more like a bug than a improvement. How would you like the feature to work - It must have a scrool bar, that simple. Current Behaviour - There is no scrool bar.
Description:Introduce a Destination Activation Replay feature that tracks failed or missed activation (e.g., due to API downtime, schema mismatch, rate limits) and allows for automatic or manual reprocessing once the destination becomes healthy again - ensuring no critical activation is permanently lost. Why is this feature important?Ensures activation reliability - campaigns or journeys shouldn't silently miss users due to transient destination errors.Helps marketers and engineers troubleshoot and recover from downstream failures without rebuilding segments or pipelines.Supports auditability and compliance, with logs showing which profiles were successfully activated, which failed, and which are pending retry.Prevents data loss during outages, especially when targeting time-sensitive audiences like flash sales or churn interventions.Current Behavior:If a destination (e.g., Facebook, Google Ads, webhook, custom API) fails during profile export, the activation fails silently or logs the error without recovery options.There is no built-in retry mechanism or UI to view, filter, or reprocess failed activations from Real-Time CDP.Users must rebuild audiences or re-trigger exports manually, which may lead to missed timing or gaps in user targeting.Use Case:A Facebook Ads destination fails due to temporary API downtime. Once it's back online, the system automatically replays the failed activation for the affected profiles.A marketer views a Delivery Health Report, sees that 500 profiles failed to activate to a custom webhook, and replays them with a single click.A team uses an export log to analyze the scope of a destination outage, informing campaign analytics and customer care follow-up.
Description:Introduce a Source Health Dashboard that monitors the status, freshness, volume, and latency of incoming data sources (batch and streaming) in real time. Add alerting features for drops in ingestion, data schema mismatches, or unusual data volume patterns. Why is this feature important?Ensures data quality and trust across the platform by surfacing real-time issues with source integrations.Reduces diagnostic time for ingestion failures that silently impact audience building or segmentation.Proactively alerts technical and marketing teams to source failures, stale data, or delays, preventing downstream impacts on campaigns and decisioning.Supports data governance and operational excellence in data-driven organizations. Current Behavior:Source connection status (e.g., for streaming or scheduled batch uploads) is not actively monitored in a centralized dashboard.Failures may go unnoticed until audience segments look wrong or campaigns underperform.There is no built-in alerting for low volume, schema drift, or ingestion latency beyond basic logging. Use Case:A key CRM source stops sending updates due to API auth failure - the dashboard shows a red status, and alerts are sent to the integration team via Slack or email.A streaming source begins sending 50% less data than average over the last 24 hours - an alert flags this as a potential anomaly for investigation.A newly added source has incorrect schema (e.g., missing a key identity field) - it’s flagged before it disrupts identity stitching or segment membership.
Description:Introduce a real-time audience fatigue scoring mechanism that tracks user responsiveness (or lack thereof) across channels (email, push, ads, etc.) and automatically adjusts frequency caps or suppresses the user from further campaigns until engagement improves. Why is this feature important?Prevents over-messaging and burnout, which leads to unsubscribes, opt-outs, and negative brand perception.Allows more intelligent campaign pacing - showing restraint can often improve long-term engagement.Reduces manual guesswork around send frequency by making decisions based on real-time engagement signals (opens, clicks, site visits, etc.).Optimizes deliverability and compliance, especially in regulated regions with communication limits.Current Behavior:Frequency capping is usually static and channel-specific (e.g., max 3 emails/week).No native cross-channel fatigue detection or unified scoring that evaluates all touchpoints.CDP does not dynamically adjust campaign eligibility based on individual user saturation.Use Case:A customer opens 0 out of 5 emails and ignores 3 push notifications in one week. Their fatigue score increases, and they’re temporarily suppressed from outbound campaigns until they re-engage.Another user is highly responsive on SMS but shows fatigue in email; the system shifts more messaging to SMS while reducing email frequency.A global brand ensures regulatory compliance by using fatigue scoring as a proactive suppression layer - minimizing opt-out rates and respecting user tolerance.
Description:In Adobe Target, once changes are made to an experience (e.g., offer content, audience rules, design tweaks in VEC), there is no built-in versioning or rollback functionality for that specific experience. If a mistake is introduced or someone wants to revert to a previously working version, it often requires manually redoing the changes or referencing screenshots or documentation - if available. Why is this feature important to you:Teams working on multiple activities across A/B tests and personalization campaigns need the ability to iterate quickly and safely. Mistakes can happen, especially in large organizations or distributed teams. Having a version history would reduce risk, support better collaboration, and speed up debugging and approval workflows. It’s especially useful for regulated industries or agencies where approval trails matter. How would you like the feature to work:Each experience within an activity should automatically store a version history whenever a change is made. This should include:A timestampThe name of the user who made the changeA summary of what was changed (e.g., audience modified, HTML updated, design edited)Users should be able to:View previous versionsCompare them visually or via a diff viewRestore a previous version with a single clickOptional: Allow notes/tags for major changes ("v1 approved", "client review", etc.). Current Behaviour:Currently, Adobe Target does not offer any version history or rollback capability. Once a change is saved and/or published, the previous version is lost unless manually backed up or documented outside the system.
Description –Managing Adobe Target activities often involves multiple roles across teams - marketers, developers, QA, and analysts. However, the current access control model does not allow fine-grained permission settings, making it difficult to delegate responsibilities securely and efficiently. For example, a QA specialist might need access to generate QA links but should not be able to modify offers or audiences. Similarly, a content editor might need to update offer text but not change targeting rules. The inability to configure such detailed roles leads to over-permissioned users and inefficient workflows. Why is this feature important to you –In large organizations or agencies managing multiple clients and campaigns, there is often a need to allow multiple team members to collaborate on activities. However, the current role-based access control lacks the flexibility to allow fine-tuned permissions (e.g., editing audiences but not offers, or managing QA links without publishing changes). This lack of granularity creates risk, slows workflows, and often forces teams to use shared credentials or workarounds.How would you like the feature to work –Adobe Target should provide customizable, granular access controls that allow admins to assign specific permissions to users or groups. For example:User A can create and edit audiences but cannot modify offers or publish activities.User B can update offer content but cannot change targeting or QA settings.A new "QA Reviewer" role can only view activities and generate QA links without edit rights.These permissions should be assignable at both the workspace and activity levels, and should support inheritance with overrides where needed.Current Behaviour –Adobe Target only offers broad user roles (e.g., Editor, Approver) that apply to entire workspaces. This often results in users having more access than they need, increasing the risk of unintentional changes or publishing errors. There's no way to restrict specific types of actions within an activity.
Request for Feature Enhancement (RFE) Summary: Enable authors to initiate workflows directly from the Content Fragments console in AEM, streamlining the content approval process. Use-case: Content authors often need to start approval workflows for Content Fragments. Currently, initiating a workflow requires navigating away from the Content Fragments console, which can disrupt the authoring flow. Use-case: Content authors often need to start approval workflows for Content Fragments. Currently, initiating a workflow requires navigating away from the Content Fragments console, which can disrupt the authoring flow. Current/Experienced Behavior: Authors must leave the Content Fragments console to start a workflow, leading to inefficiencies and potential errors. Improved/Expected Behavior: Introduce a "Start Workflow" action within the Content Fragments console, allowing authors to initiate predefined workflows without leaving the interface. Environment Details (AEM version/service pack, any other specifics if applicable): Adobe Experience Manager as a Cloud Service (AEMaaCS)/2024.03.12345.1 Customer-name/Organization name: Screenshot (if applicable): Code package (if applicable):
Description - Approvals should have a due date fieldWhy is this feature important to you - Many of the processes that require approvals in my line of work are timely and need to be received before certain activity can take place.How would you like the feature to work - I would like a due date field added to the approvals object to drive timely notifications when action is required and when. Example: A campaign (Project) has a list of drops (Tasks), with fixed start and end dates. A drop cannot occur until final approval has been received. I would want to set a Task Approval due date somewhere between 3-7 days prior to the set start date and have that trigger notifications to the Approver that they've been asked to approve and when we would need it, sending reminders as the due date approaches.
Description - I noticed that when users enter start time in Workfront (where the UI allows to specify time with up to a minute's accuracy), Fusion also adds seconds and milliseconds, which later leads to small discrepancies in processing.For example, when the user inputs the start time as 15:00 and the end time as 16:00, Fusion doesn't show 1h as would be expected after calculating the time difference but rather 0.9904197222222223h.I believe this is because 15:00 might be stored in the database as 15:00:01.500. Seconds and milliseconds can lead to subsequent inaccuracies in processing. Why is this feature important to you? Fusion gives inaccurate results when calculating time differences. How would you like the feature to work - fusion always zero out everything smaller than a minute, because UI doesn't allow for specifying anything smaller than a minute. Current Behaviour - Fusion silently and automatically modifies the time values as entered by users using the native Workfront .interface
Description:Introduce a predictive LTV (Lifetime Value) model natively inside Real-Time CDP that scores customers dynamically based on their engagement, transactions, browsing behavior, and other attributes - allowing marketers to automatically prioritize higher-value users for premium campaigns, offers, and loyalty experiences.Why is this feature important?Maximizes ROI by investing marketing resources in users who are likely to bring more revenue over time.Enables smarter segmentation beyond simple past-purchase or recency-frequency models.Enhances personalization by aligning offer types, discount levels, and campaign intensity based on user potential value.Improves strategic planning by giving marketing, sales, and service teams a predictive view of customer quality, not just quantity.Current Behavior:Marketers manually segment users based on historical transactions like total purchase value or number of orders.No predictive scoring available natively in Real-Time CDP; advanced LTV modeling typically requires external data science tools or custom machine learning pipelines.LTV-based prioritization isn't updated in real-time based on new events (e.g., sudden buying spree, major complaints, loyalty program milestones).Use Case:A user shows sudden high engagement with luxury products. The system recalculates their predicted LTV upward and automatically enrolls them in a premium loyalty tier campaign.A segment of users with declining engagement but historically high spend are identified early, allowing for targeted re-engagement offers before they churn.Campaign orchestration tools can use predictive LTV scores to decide who gets personal shopper assistance, exclusive previews, or early access to limited-stock items.
Description:Enable dynamic suppression of users from active marketing campaigns in real time based on recent negative experiences - such as failed transactions, customer complaints, or product returns - using Adobe Real-Time CDP signals and event-based triggers.Suppressed users can be re-evaluated for reactivation once an issue is resolved. Why is this feature important?Prevents wasting marketing budget by sending promotions to frustrated customers who are temporarily disengaged.Improves brand perception by respecting user sentiment and avoiding tone-deaf marketing outreach during sensitive moments.Reduces churn by showing customers you are listening and responding appropriately to their issues.Current Behavior:Audience suppression typically relies on static exclusion lists updated periodically (daily or weekly).No native real-time suppression based on live customer service data, failed transactions, or dissatisfaction signals.There’s no automated mechanism in Real-Time CDP to temporarily pause users from campaigns without manual intervention or external workflow orchestration.Use Case:A customer initiates a return request for a faulty product. Within minutes, they are suppressed from the active upsell email journey and instead flagged for a customer care follow-up.A user reports a poor app experience via feedback forms. The system immediately excludes them from push notification campaigns promoting new features until feedback is addressed.A transaction failure occurs due to payment gateway issues; the user is paused from cart abandonment reminders until the system detects a successful retry.
Description - I have created a report to pull historical data on custom fields that their format is Rich text, however the report is not showing data (the fields show empty in the report). As the WF support advised: "What happens normally when you set those fields to be tracked is that it will post the updates in the update stream and it can reference the text of the field at that time to be able to display it in the report. Rich Text is one of the only exceptions to this. Normally you can use the "Old Text Value" and "New Text Value" fields like you have, but Rich Text is stored in an HTML format in order to maintain the formatting that is being used.Because of this, though the update stream can show that updates were made, the journal entry report doesn't have a native field in it that can pull and display that HTML text. It's a rare scenario, I think this only the second time I've seen this in the last 2 years or so.In this case the only way you would be able to go about tracking changes in a report like this would be if you were to create a new field, probably a paragraph text field, so that the text can actually be referenced by the report."Why is this feature important to you - My custom fields are in Rich text format and I would like to show my users history of changes/updates to the filed over time. Unfortunately, I cannot just disregard the already created Rich text format custom fields and replace them with Text fields as there are data populated in them within the system. How would you like the feature to work - I would like there a way to create a historical report of those fields, or at least allow creation of a calculated custom field that pulls data from the Rich text format fields and converts them to text, or change the report code in a way that I can convert the rich text value to text so that the report shows the data. Current Behaviour - Right now, it is not possible to view the data from Rich text custom fields in Journal Entry reports. Journal entry fields cannot even be pulled/accessed in custom fields/forms for a workaround.
To be able to delete batches that is older than 30 days.Today those batches are not available in the view.
I'm a Workfront system admin using the admin console. Recently, I created a test user account within the Workfront instance but then shortly decided to delete that account. I deleted the test account in the console and it was successfully removed. However, it has not been removed from Workfront itself. When I contacted support to see how to delete the account within Workfront, I was told there's no way to do that and that that's intentional because deleting a user account results in that user's history being erased. As an admin, I know it's best practice to deactivate an account rather than delete it permanently. But, as noted above, there are instances when an account, whether created temporarily for testing purposes or in error, serves no purpose and needs to be permanently removed. My recommendation is for the user deletion functionality be restored to admins who are using the admin console. Even better, it would be ideal to have the ability to delete users from within Workfront AND the console depending on where you happen to be deleting from.
If a user is added to Workfront with the wrong email address OR their email address changes, it would be ideal to be able to delete the user OR update the users email address. Right now that is not possible if your organization has been connected to the Admin Console.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.