[Event Follow-Up] Leveraging the Workfront + AEM Native Integration - 10/23/25

@lesliespier That was such an insightful session, thank you, Myka and Warren, for breaking down the integration steps so clearly! 

@myka-bohnsack , When mapping metadata between AEM and Workfront, what’s your recommended approach for handling fields that don’t have a one-to-one match (for example, complex custom fields or nested metadata structures in AEM)? Do you typically resolve that through schema simplification, Fusion mapping, or custom logic within AEM?

In the presentation, it was mentioned several times that metadata sync is unidirectional from WF to AEM, however when we tested this out for one of our clients, this did not appear to be the case. We were seeing that project level data is unidirectional but document level data appears to be bidirectional. Is all metadata supposed to be unidirectional? What could be the cause of what we were seeing?

Following up from the event, Warren and Myka have answered the outstanding questions! Pasting the Q&A below.

Is 'AEM Essentials' a traditional on-prem AEM instance, or something else? 

• AEM Assets Essentials is a lightweight "version" of AEM Assets, and both are in the cloud, so not on-prem.

Is approval done in Workfront or in the creation tool itself? E.g. Figma or Adobe Express, Canva etc. 

• Approval isn't a requirement/trigger for using the native integration, so you can achieve approvals elsewhere outside of Workfront if appropriate within your content supply chain flow. 

To clarify, change management for metadata values will need to be managed in both platforms in order to work, correct? 

• Yes, that is correct. 

(Answered Live) How long, an average or ballpark, would you say you need for the preparation portion? Including the testing, etc. 

• (Notes from the live answer) Have to have taxonomy defined – assuming that’s in place and your workflow is already established. Just planning and mapping, per integration configuration, can be as rapid as one week for lower complexity scenarios, with more complex scenarios needing additional time. We have seen that the time needed for the preparation portion decreases after the first one or two native integration configurations are established in your environment. 

(Answered Live) Is the usual workflow to use Workfront Proof, to document approval, and then pushing that approved document to AEM?  How do folks deal with approving interactive documents, like PDF forms, given that's not supported in Proof? 

• Yes, that is a usual workflow, with review and approval occurring in Workfront prior to approved, final assets being added to AEM Assets. Other scenarios are certainly supported as well. Advanced document types often require review in a native tool (e.g., Adobe Acrobat) as a task that’s captured in Workfront. Once that offline task is completed, the Workfront task / approval can be updated and your content supply chain flow can continue.  

Is this example applicable to AEM in AaaCS (Adobe as a Cloud Service) or also AEM 6.5? 

• You do need to be on a cloud-native version of AEM Assets to utilize the native integration, which would be AEM aaaCS Assets or Assets Essentials. 

Version question: How is an asset determined to already exist in AEM when an asset is uploaded to the linked folder in WF? Is it file name matching or is there byte comparison? 

• The integration will create a new version of an asset in AEM Assets if the target AEM asset is explicitly matched by filename and AEM folder path. 

When moving the metadata from Workfront to AEM. Can you append the AEM field with the Workfront metadata? 

• No, the integration will populate and replace metadata field values in AEM. It will not append metadata to existing AEM metadata field values. This also applies to AEM dropdown fields with multi-select enabled. 

If a file in AEM is used for Workfront Proofing, do the comments from the proof add to the Assets Comments in AEM? After Workfront Proofing, If the file is replaced with an edited file should the edit be uploaded to AEM as a version of the original? 

• The native integration does currently support Proof documents, but comments in Proof do not currently carry over. 

Has the old AEM/Workfront connector for on-prem installations (and folks on managed services) been deprecated? Is Fusion the recommended solution now? 

• The enhanced connector has not been deprecated, but it's not the go-to for AEM AaaCS or Essentials; the native integration is. Fusion is a possibility with both usages of the enhanced connector or the native integration for fill in any use case gaps. 

Is the node limit a Workfront limitation or a EDAM limit (e.g. Adobe Assets)? Or a limitation on the integration? 

• The node limits for the integration are based on specific integration limits, which do also consider node limits in AEM. 

If we automate it, would this be done via Fusion or do we have bulk options or can we have something like inherited metadata for all documents in a project? 

• Fusion can be used to automate metadata application on Documents in Workfront prior to the native integration sending assets to AEM Assets. In AEM Assets, folder metadata profiles, smart tagging and/or any custom workflows or listeners/event receivers can be applied to automate tagging in bulk. 

What is best practice for handling assets that are larger than WF's 4 GB upload limit? Should we direct clients to directly upload them in AEM and then go back to WF to apply metadata? 

• There are plans to increase that upload limit. Stay tuned! Meanwhile, yes, uploading very large files directly to AEM works well, however the metadata should be applied directly in AEM because the native integration works best when the assets are uploaded directly to Workfront before the assets are added to AEM. 

I have a current Fusion scenario that processes new Projects. One of the steps in the scenario creates folders in the Workfront Project based on tasks in the project. Could I edit this Fusion scenario to create project folders in AEM instead? 

• Yes you could use Fusion to create folders in AEM directly, but if your use case supports it, you can also define linked folders within the native integration configuration that would effectively templatize the creation of folders in AEM when the integration pushes assets from Workfront. 

What about localization? Any best practices? 

• The native integration works best in localization scenarios when both the Workfront Document folder structures and the AEM Assets folder structures are aligned in a manner that supports your localization goals. For example, if your AEM Assets folder structure support locale-specific folders, the native integration can be configured to create linked folders that adhere to that locale-based folder structure. 

Using field attributes from Workfront objects - is there capability for the systems to automate naming of the asset files using this setup? 

• The native integration can be used to leverage Workfront objects for folder names that are part of the integration as folder trees and linked folders, but document filenames cannot be updated as part of the native integration. Fusion can be used pre-execution of the native integration to use Workfront objects to adjust Document names in Workfront. 

Can AEM Assets Taxonomy tags be mapped as well? Or does this only work for simple fields/attributes? 

• Yes, AEM’s Tagging fields can be mapped via the integration. Note that choice values in Workfront must be set to use the exact AEM tag property names that appear in an asset’s AEM metadata, when that tag is applied to an asset. For example, a multi-select dropdown field in Workfront can be used in a custom form, with choice values that explicitly match AEM tag property values. That multi-select dropdown field can be mapped in the native integration to a Standard Tags metadata field in your AEM metadata schema. Note that the default “cq:tags” Standard Tags field in AEM is not available for the integration. Standard Tags fields that you add to your Touch UI Metadata Schema Forms in AEM are available in the native integration configuration. 

I see Brand Portal! Is this an Adobe portal? 

• Yes, Adobe’s Brand Portal product is natively integrated with the Workfront | AEM Native Integration. If considering Brand Portal as a new implementation, consider its successor, Content Hub. 

Are there plans to expand the default Object Data list to allow more custom WF fields rather than just program, portfolio, project, or project creation year for automatically generated folders? Are there plans to allow auto-publish to Content Hub in the near future or is it best practice to not enable auto-publish workflow for prod environments? 

• Great suggestion! We’ll provide your feedback to the appropriate Adobe Product team. 
   
  From a best practices point of view, auto-publishing from Workfront through to AEM activation destinations should only be applied in cases where metadata enrichment via AEM (after the assets are sent via the integration) is not beneficial or required, and when there is certainty that any auto-publishing risks have been mitigated fully. If that criteria is met, as well as any implementation and business-specific criteria for auto-publishing, it may be beneficial to enable the native integration’s auto-publish options. 

Are you also showing where these assets would show up? In the project or in the campaign in planning or both? 

• In Workfront, the assets remain in the Project. In AEM Assets, the assets show up in the folder/folder tree that is specified in the project’s native integration configuration. 

Can you create a Workflow that puts all WIP files from several other document folders into one WIP folder on AEM? And then separately link the Final folder to Content Hub folder? 

• Yes, this can be achieved within one or across many Workfront projects. There wouldn’t necessarily be a pull from any created WIP folders in Workfront, but created WIP folders can be linked via the native integration as linked folders, with each pointing to the AEM final folder. Multiple integration configurations can be used to establish folder trees in AEM that incorporate unique AEM /final/subfolder names, or approval tasks / processes in Workfront can be added to validate filename uniqueness before approving Workfront documents as final. 
   
  From there, publishing those assets to Content Hub from AEM Assets would function as normal. 

I'm new to Adobe products - I'm seeing AEM and AEM Content Hub in my dashboard, can anyone tell me the difference/uses for each? 

• AEM is the core Content and Digital Asset Management platform within the Adobe Experience Cloud ecosystem. Content Hub and Brand Portal are two add-ons to AEM that enable end users to find, view and download (among other end-user-centric functions) asset that are published from AEM Assets. 

Wait, content hub has folders aside from collections? 

• Content Hub does not have a folder structure. Permissions rely on metadata. 

I saw "Brand Portal" on this demo and we have Content Hub. Are they the same? 

• Content Hub is the successor to Brand Portal, and Content Hub provides features beyond those of Brand Portal. 

Which AEM metadata fields show up in the connector for mapping? Those defined in Touch UI or newer asset UI? 

• AEM metadata fields created in the Touch UI (also known as the Admin View) show up in the integration. Fields added via Assets View Metadata Forms do not currently appear in the native integration configuration options. 

Is there a way to auto distribute assets to AEM once proofing approval is done in WF? 

• You'd want to invoke this with Fusion or to manually move the approved Document(s) into a linked folder in the Workfront Project, which could trigger the native integration. 

Hm so just the ID not the name of the campaign? 

• Yes, Campaign Name values can be mapped in the native integration, as well as many additional fields. In the demo, the Campaign ID was mapped as an example, as Campaign IDs are great to use for downstream campaign and asset effectiveness reporting. 

Are there any guardrails on the Workfront side to stop Workfront users from uploading bad assets or is it entirely reliant on AEM permissions? 

• Workfront supports scanning for corrupt documents, upon request. Additionally, there is often an approval process associated with the Workfront project that a native integration is enabled for. That approval process often has approval steps to review uploaded documents. 

Are there plans to update the user experience to enable automated moving of assets from WF folders to linked folders based on a WF event instead of requiring either Fusion or manual moving of assets? 

• Not at this time, although as mentioned in the question, Fusion can be used to accommodate this request. 

Can a clickable URL back to the Workfront project be added in the AEM metadata schema? 

• Partner: Based on my last project, AEM does not have an OOTB URL field so we were only able to include the link that users would have to copy/paste. Adobe: This is correct! 

In the slides you were showing and in this demo, the assets being referenced are images, is that the primary use case for AEM and these integrations? 

• Moving images to AEM is a common use case for this integration and for content supply chain efforts, but the native integration is not limited to images only. The native integration supports files that can be uploaded as Workfront Documents. 

In the demo, it looked like you're able to send multiple assets from Workfront via the native integration, is that something you had to set up in a special way? 

• Yes, the native integration can send multiple documents in one action. No special configuration is needed, as the integration will send all applicable documents in the same submission to AEM Assets. If sending manually, select the applicable documents in Workfront prior to selecting the native integration configuration. If sending via linked folders, ensure all the documents are in the appropriate linked folder. 

Do we need fusion for bidirectional metadata sync in the cloud? We are using enhanced connector and we are on AMS, planning to migrate to cloud. 

• Yes, you'd achieve bidirectional flow of metadata with Fusion. 

How do you handle documents that get frequent revisions, particularly from the Workfront side? Do you keep everything in one project and re-open and have a long list of tasks, or do you start new projects per-revision and somehow update the correct files in AEM during publishing? 

• If the documents are revised multiple times prior to final approval, we recommend only sending the final approved document to AEM. 

• If the documents are revised, approved, then revised again after approval, it is common to start a new project with tasks specific to revising an asset that has been previously approved. The native integration configured for those projects can be configured to allow the documents, once re-approved, to be added to the original location in AEM with the same file name, which would  create a new version of the asset in AEM. 

How would you recommend uploading / multiple assets that have unique metadata values, meaning each asset has unique keywords, Document ID numbers, etc? 

• In Workfront, each Document can have its own document-level metadata applied using the native Document Details form and/or custom forms added for Documents. Those Document-level fields can be mapped in the integration. If it’s practical for Document uploaders to apply metadata to Documents in Workfront, this approach should be used. 
   
  However, it is common for Document-specific metadata to be applied via AEM Assets in bulk using templated spreadsheets, after the Documents have been migrated to AEM from Workfront.