Two systems, one file, and a gap between them that people fill by hand. Work is planned, assigned and approved in one place; the approved asset is stored, tagged and distributed in another. Between them sits a download, a re-upload, and uncertainty about which copy is the real one.

Adobe Workfront and Adobe Experience Manager Assets are built to close that gap directly rather than through a nightly job. The mechanics are worth understanding before a contract is signed: the connection is not one product but three generations with different prerequisites, limits and futures, and picking the wrong one is expensive to unpick.

Table of contents

1. What is the Workfront and Experience Manager Assets integration?
2. Three ways to connect them, and only one is current
3. What crosses the border, and in which direction
4. What to plan for: licensing, storage and size limits
5. Conclusion: why the connection is a design decision

What is the Workfront and Experience Manager Assets integration?

The current mechanism is a native integration, configured inside Workfront, that keeps folders linked between the two systems so that the work object and the asset location are the same location. Our Adobe Workfront page owns that topic and describes linked folders and their prerequisites; this article covers what that page has no room for — which generation you are on, and what crosses the border.

Responsibility splits in a way that matters for planning. A Workfront administrator configures the Experience Manager integration; only after that can users with a Standard or Plan license set up linked folders on individual projects. So the first step is administrative, with organization-wide consequences, not a per-project convenience — and one limit follows the folder itself: Adobe states that you cannot create a new document or proof version inside a linked folder.

Three ways to connect them, and only one is current

The vocabulary here is not decorative: a connector is software installed into Experience Manager, while the integration is configured inside Workfront.

The legacy connector is the oldest and now mainly a starting point for migration. The enhanced connector is the Experience Manager-side component, and Adobe is explicit about how it may be deployed: deployment and configuration only via certified partners or Adobe Professional Services, otherwise it is not supported. Adobe supports versions 1.7.4 and higher, and warns that updates to either product may make the connector redundant, in which case customers may be required to transition away from it. Its documented platform support is wider than its current role: the connector overview lists Experience Manager Assets as a Cloud Service alongside Experience Manager 6.5 Assets on-premise and as a Managed Service, but for Assets as a Cloud Service new implementations are blocked — so the 6.5 environments are where it still applies.

The native integration is the current answer, and Adobe dates the change precisely. As of June 2022 the native integration for connecting Workfront with Experience Manager Assets as a Cloud Service "has become the required method for connecting these two solutions," and — in Adobe’s own words — "any future new implementation of the enhanced connector (1.9.8 and later) to connect Workfront with AEM Assets as a Cloud Service is blocked." Running both is not an option either: Adobe does not support using the legacy or enhanced connectors and the Experience Manager integration in parallel.

Which migration path applies to you depends entirely on where Experience Manager lives, and Adobe scopes the two documents against each other. The route from legacy to the enhanced connector "applies only to customers using Adobe Experience Manager Assets On-Premise or Managed Services environments." The route to the native integration carries the mirror-image notice: it "does not apply to customers using Adobe Experience Manager Assets On-Premise or Managed Services environments," and it begins with tying the Workfront environment to an Adobe Admin Console — a migration Adobe must help carry out.

What crosses the border, and in which direction

Everything in this section describes the native integration. The generation matters here more than anywhere else: among the enhanced connector’s capabilities Adobe lists bi-directional metadata syncing, while in the native integration metadata is the part most often assumed to be symmetrical — and it is not. Adobe states it flatly: "You can map metadata only in one direction: from Workfront to Experience Manager," and "metadata for documents linked to Workfront from Experience Manager cannot be transferred to Workfront." Within that direction the cardinality is also fixed — a single Workfront field can map to multiple Experience Manager Assets fields, but multiple Workfront fields cannot map to a single Experience Manager field.

Timing matters as much as direction. Mapping happens when an asset is pushed from Workfront for the first time, so the mapping configuration must be right before the first asset moves, not after somebody notices empty fields. Once assets are flowing, Adobe documents that mapped Experience Manager fields update automatically when the corresponding portfolio, program, project, task, issue or document field changes in Workfront.

One choice is genuinely final. The Experience Manager Assets repository is selected during the initial configuration, and Adobe warns that due to the complexity of the integration you cannot change the repository after saving that configuration. That is why we treat repository selection as an architecture decision, not a setup field.

What to plan for: licensing, storage and size limits

The access requirement is modest and stated per capability: creating a linked folder needs "Adobe Workfront package: Any" with a "Standard" or "Plan" license, plus write access to the destination folder in Experience Manager. Storage accounting is less neutral, and its documented scope is Assets Essentials: documents uploaded and sent from Workfront to Assets Essentials still count against your overall Workfront document storage, while assets linked from Assets Essentials do not. So "link from the library" and "upload into the work" have different costs.

There is a hard ceiling too: assets sent to Experience Manager through this integration have a size limit, and it differs by connector and environment — Adobe’s own pages give different numbers, so confirm the one that applies to your setup before planning large-file work. One more generation caveat sits here: linked folders are not available in the new Documents area, so an organization on Adobe cloud storage can add Experience Manager assets but cannot create one. What the library then does with the arriving file — metadata models, processing profiles, tagging and the approval state that governs distribution — is on our AEM Assets / DAM page.

Conclusion: why the connection is a design decision

The value of joining these two systems is easy to state and easy to underestimate: work and its output stop living in two separate places, so the approved file is not exported, renamed and hunted for a week later. What determines whether you get that value is a short list of decisions made early — which generation of connection applies to your Experience Manager deployment, which repository, which metadata mapping, and which route your teams use to bring files in.

Softwhale designs both sides of that border, because a metadata model that suits the work management side and fails the library side is a problem nobody owns. Our Adobe Workfront page describes how we scope the integration and where a project starts. Scoping both sides of that border is typically 3–4 weeks before configuration starts, and the metadata model agreed there is what keeps the two systems from drifting apart later.