Product ideas | Adobe Experience League Community
Skip to main content

Ideas

Filter by idea status

10000+ Ideas

LeaPe1Level 1

Sharing of Proog for Light and Contributor usersNew

FEATURE : As a light/contributor/standard user (Reviewer and/or Approver), I want to be able to tag in a comment another user who is not in the workflow. This person should then be able to comment the proof but not make any decision Currently, in Adobe Workfront Proofs, users can only tag (@mention) individuals who are already explicitly added to the workflow (as a Reviewer or Approver).If a project team member needs quick input, clarification, or a second opinion from a colleague who is not part of the pre-defined workflow, they cannot bring them into the proof directly via a comment. Instead, the user has to manually reach out via email/chat, export screenshots, or request an administrator to modify the workflow and assign permissions—all of which creates friction, delays feedback loops, and disrupts collaboration. Business Impact & BenefitsAccelerated Review Cycles: Eliminates bottlenecks caused by rigid workflows, allowing ad-hoc subject matter experts to weigh in quickly without administrative overhead. Improved Cross-Functional Collaboration: Bridges the gap between core project teams and wider stakeholders who only need visibility or light input. Maintained Governance: Preserves the integrity of the formal approval process since non-workflow invitees can only comment and cannot make binding decisions. Enhanced User Experience: Reduces manual workarounds (like screenshots and external messaging), keeping all feedback centralized within Workfront.

JavierGi1Level 1

Improve API documentation by listing required permissions for each endpointNew

As global platform administrators, we are responsible for creating Developer Console credentials and distributing them to each sandbox administrator. These credentials are intentionally configured with the minimum permissions required to perform the requested action.Today, when a sandbox administrator requests access to a capability such as Data Ingestion, we can find the API documentation that explains the available endpoints and how to use them. However, we cannot find clear information in either the API documentation or Experience League about which specific permissions are required for each operation.For example, the documentation may describe a method such as POST – Create a new batch, including the request format and usage, but it does not indicate which AEP permissions must be assigned to the Developer Console credential in order to execute that operation successfully.Requested improvement:Please add, within each API method or endpoint documentation page, a small highlighted section that clearly states the required permissions/roles/scopes needed to use that operation.Example:For POST – Create a new batch, include a note or box indicating the exact AEP permissions that must be granted to the credential in Developer Console.Why this is important:Helps administrators assign the correct minimum permissions from the start Reduces trial and error when configuring credentials Speeds up onboarding for sandbox administrator and teams consuming the APIs Improves security by reinforcing least-privilege access Reduces support requests caused by missing or unclear permission requirements

SameekshaAdobe Employee

Data Distiller | AcceleratorsNew

OverviewData Distiller Accelerators help users move faster from raw data to repeatable analysis by providing Adobe-authored SQL templates for common business, industry, and technical use cases. Accelerators are available in the Queries workspace and can be used to analyze areas such as customer segmentation, campaign performance, commerce behavior, audience overlap, fraud detection, retention, product reviews, attribution, and more. Access and PermissionsAccelerators are available to organizations with Data Distiller entitlements. Users can access them from the Accelerators tab in the Queries workspace. Viewing Available AcceleratorsGo to Queries in the left navigation, then open the Accelerators tab.The accelerator catalog displays available templates with a name and description, making it easy to identify the right starting point for your use case. Using an AcceleratorSelect an accelerator to open it in Query Editor.The SQL is preloaded and read-only by default. Users can provide the required parameters, run the query, and review the results directly in the Results tab. Saving or Scheduling ResultsAfter validating the output, users can persist results into a dataset using CTAS or schedule the accelerator to run on a recurring basis with fixed parameter values.This helps teams turn one-time analysis into repeatable workflows. Customizing AcceleratorsAccelerators are maintained by Adobe and cannot be edited directly.To modify the SQL, users can create a custom template from an accelerator. The cloned version becomes editable and can be saved, scheduled, or adapted to fit organization-specific business logic. SummaryData Distiller Accelerators provide trusted SQL starting points across a broad range of use cases. They reduce manual SQL authoring, help standardize repeatable analysis, and give teams the flexibility to operationalize or customize workflows as needed.Author: ​@Sameeksha

jigar-shahAdobe Employee

From Gut Feeling to Grade Point: How AJO Measures Service QualityNew

 From Gut Feeling to Grade Point: How AJO Measures Service QualityHow we grade every service behind Adobe Journey Optimizer — and what happens when a grade slips. When you're running customer journeys that depend on Adobe Journey Optimizer, you're trusting that the platform underneath is holding up its end—every trigger fires, every send lands, every integration behaves the way it should. That trust is something we take seriously, and we've built a system to hold ourselves accountable to it in a very concrete way: the Service Scorecard.The Service Scorecard gives every service that powers AJO an automated grade, refreshed twice a day, across four dimensions that together define what “healthy” means: how well we respond when incidents happen, how thoroughly the code is tested before it ships, how much reliability margin we're maintaining against our own commitments, and how quickly we act on reported issues.This is part of a wider effort across Adobe Experience Platform to apply one consistent quality bar everywhere—and AJO has seen some of the strongest gains in reliability and responsiveness as a result. Why These Four DimensionsEach dimension maps to a distinct point in a service's operational lifecycle:Before code ships — automated test coverage (Code Quality) While it's running in production — reliability against SLO commitments (Reliability Against Our Commitments) When something breaks — root-cause closure and corrective action completion (Incident Follow-Through) When a customer reports an issue — resolution time against SLA (Speed of Resolution) Four Dimensions, One GradeRather than judging a service by a single metric, the Scorecard looks at the full picture. Each service earns a letter grade, A through F, based on:🧪  Code QualityThis dimension measures automated test coverage—the percentage of a service's codebase exercised by automated tests. Coverage is tracked per service and rolled into the score as a direct percentage. Higher coverage is a leading indicator of fewer regressions across releases.⚡  Reliability Against Our CommitmentsEvery service has a reliability target—a service-level objective (SLO)—that it's expected to meet, and this dimension tracks the error budget remaining against that target. The calculation pulls reliability data across AJO's internal service dependencies, so if a service depends on another AJO service that's degraded, that impact is reflected in this score—even though the dependency relationship itself isn't shown directly. This dimension is scoped to dependencies within AJO; it doesn't extend into upstream platforms like Adobe Experience Platform or Real-Time CDP.🚨  Incident Follow-ThroughThis dimension is measured against committed SLAs for incident resolution and root-cause closure. It tracks whether root-cause analysis and every corrective action tied to a CSO (Critical Service Outage) are fully completed—not just whether the incident was mitigated. A CSO isn't marked closed in this score until every associated action item is actually done.🐛  Speed of ResolutionThis dimension tracks how quickly reported issues get resolved, weighted by severity against SLA targets. That includes issues reported through Adobe Support, as well as issues caught internally before they ever reach a customer—including bugs caught through our automated Customer Use Case (CUC) testing, which runs real customer scenarios end-to-end against every release candidate. A critical, widely-felt issue is held to a tighter SLA than a low-severity edge case, and that weighting is built directly into the score.We covered CUC testing in detail in an earlier post: Catching Bugs Before Customers Do. A service's overall grade blends the dimensions that apply to it:A Excellent — low risk, high discipline B Good — healthy, minor gaps C Acceptable — attention needed D Poor — active remediation underway F Critical — immediate escalation Every service on AJO is held to a bar of B or better across all four dimensions. Why We Built It This WayA grade only matters if it's trustworthy, so we designed the Scorecard around a few principles:The same yardstick, every time. Every service is measured identically, so a grade means the same thing no matter which team or capability you're looking at. Updated twice a day, not quarterly. Grades roll forward continuously, so what you're looking at reflects current reality, not a stale snapshot. A named owner for every score. Each service has someone directly accountable for its grade, with clear visibility into exactly what's driving it up or down. Zoomed in or zoomed out. The same data supports a leadership-level view of overall platform health and a team-level view of a single service—so everyone from an engineer to a director is looking at the same underlying truth. A FAIR QUESTION We know the obvious one: doesn't self-grading just let a team grade itself easy? Every score comes from the same systems—incident tickets, test coverage, reliability dashboards, support tickets—used organization-wide, not something a team curates. And the bar itself is fixed platform-wide; no team can lower it to flatter its own grade.   How a Grade Gets MadeThis is the core of the Scorecard: a single algorithm that calculates each of the four dimension scores for every service, independently, across every production region that service runs in—using the same formula and the same thresholds everywhere. Standardization is what makes an A in one region comparable to an A in another, and what makes a director's platform-wide view and an engineer's single-service view consistent with each other.The Service Registry is the backbone this rolls up from. It's the source of truth for which services exist, who owns each one, which capability each service belongs to, and which regions it runs in. Every rollup—service to capability, capability to platform—is driven by the Service Registry's ownership and grouping structure, not by any team's own reporting.Each dimension draws on its own signal: Support & Incident Tickets for Incident Follow-Through, Automated Test Coverage for Code Quality, Support tickets plus automated Customer Use Case testing for Speed of Resolution, and Reliability Monitoring for Reliability Against Our Commitments. Those four scores blend into one A–F grade per service, calculated per region and then rolled up—using the Service Registry's structure—into an overall picture of platform health. Four per-region signals blend into one grade; the Service Registry drives every rollup from service to capability to platform. When a Score Slips, Deployments WaitA grade isn't just for visibility—it drives real action. When a service's grade falls below our bar, it becomes a candidate for what we call quarantine. Leadership reviews the full picture—score, incident history, team capacity, business impact—and services selected for quarantine enter a focused remediation period: production changes pause, including hotfixes, unless leadership explicitly signs off on an exception, while the team's full attention shifts to a concrete set of fixes.Getting out of quarantine takes more than a single number recovering. A service has to reach an overall B grade—and get sign-off from engineering leadership that the underlying risk is genuinely resolved, not just papered over. To be clear : Quarantine doesn't mean a service stops running—your existing journeys and campaigns keep operating. It means that team's roadmap pauses so they can focus entirely on the fix.  We take this stance deliberately. A low grade on any of the four dimensions is a signal that a customer, somewhere, is already feeling the effects—whether that's a slower resolution time, a reliability gap, or an incident that hasn't been fully closed out. Shipping new capabilities on top of that isn't a trade-off we're willing to make.This also puts real ownership in the hands of the engineers closest to the work. Rather than quality being managed from a distance, the teams who know a service best are the ones empowered—and expected—to fix it. What This Means Going ForwardThis system is built to catch and resolve issues before they reach you—minimizing customer impact is the goal behind every one of these four dimensions, from root-cause closure to error budget tracking to resolution SLAs. It gives us a continuous, standardized way to hold every service to the same bar, across every region, and act before a quality gap turns into a customer-facing problem.That's what lets your journeys, campaigns, and customer experiences run the way you'd expect them to, day in and day out.  COMING NEXT IN THIS SERIES How we're using AI to onboard every AJO service onto a standardized set of service-level objectives—turning a process that used to require deep manual expertise into something fast, consistent, and automatic. Stay tuned.  Authors: Shivam Chamoli, Kevin Cabral, and Jigar Shah

ncdd23Level 2

Autosave/Drafts for Requests being Created within a ProjectNew

Description - After a thorough implementation, we decided to use the Request Queues built directly in the projects. The functionality is great. We have a project template set up with Queue Topics, Groups, Forms etc. The issue is that when creating requests directly in a project there is no Autosave or Drafting functionality that we know of. Our users are becoming increasingly agitated by having complex requests easily deleted at the unfortunate click out of the request window or accidental refresh of the page.   Why is this feature SO VERY important to you - Our current solution is to submit requests without auto-routing to a traffic team so the work can be saved. Leading to needing to save as you go, something that is antiquated in this day and age, especially knowing that autosave exists in many other places in Workfront, including the Global Request Queues area.   How would you like the feature to work - simply autosave as you go with a Drafts section built into the Request area of the Project. Or a new section called Request Drafts. Draft autosaves until the Submit Request button is clicked.    Current Behaviour - User begins a request, fills out info and has to Submit the Request in order to save it and continue working on the request, and they must click save as they progress. If users haven't submitted the request yet or haven't recently saved, it is very common for users to accidentally click out of the window, closing the request and clearing all the info. Leading them to have to painstakingly recreate the request they could have spent many hours on.   Please prioritize this, WF.