Skip to main content

Ideas

Filter by idea status

10000+ Ideas

AlexCa20Adobe Employee

Workfront Proof: Improve Color Fidelity and ICC Profile Handling When Rendering Overprint and Multi-Layer FilesNew

Problem StatementCustomers are reporting color discoloration and washed-out rendering in Workfront Proof that does not match the original processed creative assets. This issue is particularly visible in color-sensitive review and approval workflows where proof accuracy is critical for validation and sign-off.The issue appears to be related to changes previously made to support overprinting and multi-layer PDF rendering. While the prior enhancement resolved a separate issue involving varnish and multi-layer content not rendering correctly (Reference: #00442736 - Environment Discrepancy: Varnish Layers Failing to Render in Capital One Proofing Viewer), customers are now experiencing color discrepancies that may be an unintended side effect of those rendering adjustments.Business ImpactReduces trust in Workfront Proof as an accurate representation of final creative assets. Creates confusion during review and approval workflows. Impacts customers with color-critical use cases, including print production and packaging workflows. Forces users to rely on external validation methods outside of Workfront Proof.Current StateWorkfront Proof reprocesses uploaded files for viewer display and renders content in sRGB. Rendering behavior can be affected by embedded ICC color profiles and proof processing settings. Current guidance requires customers to manually adjust files prior to upload by: Converting assets to sRGB Embedding color profiles Flattening PDFs before proof generation There is currently no product-level workaround that preserves intended color output while also maintaining support for overprinting and multi-layer rendering.Requested EnhancementInvestigate and enhance the proof rendering engine to:Preserve color fidelity more accurately during proof generation. Improve handling of ICC color profiles, overprinting, and multi-layer PDF content. Eliminate or minimize color shifts introduced during proof reprocessing. Maintain support for the existing multi-layer/varnish rendering improvements without requiring customers to flatten or otherwise modify source files. Provide users with greater visibility into applied color conversion and rendering behavior when proofs are generated.Desired OutcomeCustomers should be able to upload professionally prepared creative files and receive a proof that accurately represents both:The intended visual color output, and Multi-layer/overprint rendering behaviorwithout requiring manual preprocessing, file flattening, or color profile manipulation prior to proof creation.Related ReferencesDefect/Support Ticket: E-002306339 Previous Ticket: E-002157738 Related Issue: #00442736 - Environment Discrepancy: Varnish Layers Failing to Render in Capital One Proofing Viewer

Audit Trail & Activity History for Assets in Adobe Experience Manager (AEM)New

We are currently using Adobe Experience Manager (AEM) as a core platform for managing and publishing imagery to our website. However, there are significant limitations around auditing and activity tracking, as there is no comprehensive audit trail available for us to utilise. This creates challenges for operational processes, including complaint investigation, troubleshooting issues and understanding when and how changes have been made within the system. Currently, key activities such as asset uploads, metadata updates and publishing to the live website cannot be tracked. Internally, we have identified multiple gaps where audit visibility is either limited or not available. Use Case / Problem:Without an audit trail, we are unable to:Identify when an image was changed or replaced on the website Trace who made specific metadata or asset updates Investigate discrepancies or bugs more efficiently, enabling us to respond to complaints with greater confidence and accuracy. Maintain a clear historical record of asset activity across product pages This leads to increase manual investigation, reduced accountability and slower resolution times. Requested Enhancements:We would like AEM to provide a clear and accessibly audit history covering the following areas: 1. Asset Creation via Workfront FusionVisibility of who uploaded an asset into AEM Details of the upload date and time Ability to trace source system (e.g. Workfront Projects) 2. Asset ModificationsFull history of changes made to an asset Details of what was modified (e.g. metadata fields, tags, captions etc.), for both Adobe’s out-of-the-box functionality and any custom-developed features Date and time of each change User who made the change 3. Publication TrackingRecord of when an asset was published to the website Identification of who triggered the publication Visibility of when assets were unpublished and archived 4. Product Level HistoryAbility to view publication history at a product level Timeline of when assets were added, updated or removed.  Benefits:Introducing auditing capabilities would deliver clear benefits such as:Faster and more accurate complaint investigations Improved troubleshooting and root cause analysis Greater visibility and accountability across teams Reduced reliance on manual tracking and workarounds Stronger governance of digital asset management processes

Expose Resource Availability Data Through the Workfront MCP ServerNew

SummaryOur team uses Claude connected to the Workfront MCP server to answer resourcing questions in natural language. Planned Hours are fully and reliably queryable today. Remaining Available Hours — the metric the Resource Planner itself calculates (schedule capacity minus time off minus existing commitments) — is not exposed through any MCP tool, and cannot be reliably reconstructed from what is exposed. We're requesting this data be made queryable so a team's full capacity picture (Planned + Available) can be surfaced through natural-language requests, not only through the Resource Planner UI.What Works TodayPlanned Hours are cleanly queryable via the insights_find_workfront_data tool, using fields such as assignment.assignment_workRequired and task-level planned hours, grouped or filtered by user, project, or date range. This lets Claude answer questions like "how many planned hours does each person on this team have this month" accurately and immediately.The GapThe Resource Planner's own Available Hours (AVL) value — schedule capacity minus time off minus hours already budgeted across all of a user's projects — is not exposed as a field through insights_search_fields or any other MCP tool we've found. The raw inputs needed to approximate it are also incomplete: user.user_workHoursPerDay and schedule.schedule_hasNonWorkDays are queryable, but time off is only exposed as a boolean flag (user.user_hasReservedTimes), not as actual date ranges or hours. There is no queryable list of a user's specific time-off periods or schedule exceptions. As a result, Claude cannot reliably reconstruct "remaining availability" even by combining multiple queries — any approximation would overstate availability for anyone with time off on the books, since those dates aren't visible to any tool.What We're RequestingPreferred: expose the Resource Planner's calculated Available Hours (AVL) value itself as a queryable field — per user, role, or project, scoped by date range — mirroring what already displays in the Resource Planner UI. Minimum viable alternative: expose the underlying time-off / schedule exception data (specific dates and hours per user) as queryable fields, so Available Hours can be reliably approximated by combining it with the Planned Hours data that is already accessible.Why This MattersCapacity planning conversations need both halves of the picture — what's already committed, and what's actually left. Today, getting the Available Hours half requires manually opening the Resource Planner and checking user-by-user, project-by-project, which doesn't scale and can't be surfaced through natural-language tools like Claude. Closing this gap would let our team ask capacity questions the same way we already ask planned-hours questions — directly, without a manual UI detour.

Section Headers & Table Of Contents - Possible ways to improveNew

Both the Section Headers and Table Of Contents have been good additions for making reports easier to read and navigate through - though have got a couple of thoughts on how they might be able to be improved further. 1) Add the full set of right-click functionality to Section Headers - At present, the only way that the Section Header visual can be interacted with is changing the text; the right-click menu that exists with other visualisation types isn’t there. However, I think it would be good to change this for two main reasons. ‘Edit description’ - This could be used to enable the adding of a short description or subtitle, between the main title and the line underneath the visualisation. ‘Get visualisation link’ - It would be good to be able to link directly to a Section Header. As a user who often adds an Introduction or Contents section to tell users what they can find in a report, it’s nice to add links in, but currently you have to link to any other visual that’s close to the Section Header instead. Although doing this ‘Contents’ part does overlap with the Table Of Contents feature, I find a) many more ‘casual’ users are still unaware it exists, and b) this written text is far easier to quickly understand due to the next point… This right-click menu exists on other visualisation types, but not Section Header. Distinguish Section Headers in the Table Of Contents - In the below image of the Table Of Contents on the left, you can’t instantly see which lines are Section Headers. As a result it’s a lot more tricky to find what you’re looking for and understand what’s in the panel. Some possible changes (as per the right) that could improve this may be adding bold text to Section Headers, indenting any text that isn’t a Section Header, or even adding in icons to distinguish the visualisation type next to each line. At the moment I often find myself adding colons to the text of these visuals only, or adding extra Section Headers with ‘-’ as the title to create a space, as something of a workaround to get them to be somewhat visually identifiable. The left image shows how the current Table Of Contents displays, while the right image shows how this could look using bold text for Section Headers or indented text for other visuals. With these changes though, hopefully it would make dashboards easier to read and navigate. 

新しいEメールデザイナと旧EメールエディタのAPIについてNew

Marketoのメールアセット一覧とメールコンテンツ取得に関して、現在の検証結果として下記だが、v2仕様は公開情報となっていない。また、メールアセット一覧取得に関して、v1で旧エディタでの作成分と新エディタ作成分(ただしレスポンス内容の不足あり)という状況だが、この状態が正式仕様となるのかも公開情報となっていない。 APIを利用したシステム構築を行ううえで正式な仕様情報がなく、設計が困難なため早期に仕様の確定および公式情報として公開を頂きたい。 《検証結果》■メールアセット一覧取得 v1:旧エディタに加え、新エディタで作成したアセットも取得可能。ただし新エディタ分は、一部Subjectが含まれないなどレスポンス内容に不足が見受けられます。   (https://developer.adobe.com/marketo-apis/api/asset#operation/getEmailUsingGET) v2:新エディタで作成したアセットのみ取得可能。   (https://developer.adobe.com/marketo-apis/api/asset#operation/filterContentUsingGET_email)■メールコンテンツ取得 v1:旧エディタ作成メールのみ取得可能   (https://developer.adobe.com/marketo-apis/api/asset#operation/getEmailFullContentUsingGET) v2:新エディタ作成メールのみ取得可能   (https://developer.adobe.com/marketo-apis/api/asset#operation/getContentUsingGET_email)