Leveraging the Workfront + AEM Native Integration

Transcript

All right, welcome everyone. We’ll get started here. My name is Leslie Spear. I’m part of the Workfront Scale Customer Success team. And we are lucky today to have Warren Barton and Micah Bomsack with us today to talk about the Workfront Native Integration with AEM. So just a few housekeeping things. Right now, everyone is set to no camera and on mute. We might disable or enable those things later so that you can ask questions. We’re gonna kind of hold questions until the end. The chat is available. We do have a couple folks hanging out in the chat if you wanna ask some questions there. We’ll try and get to those and answer to the best of our abilities, but anything we don’t get to, we’ll try and answer later.

You will get a copy of the slides and the recording via email, and we’re gonna try and share it on Experience League as well.

I think that’s it. So I’m gonna hand it over to Micah.

Okay. Okay, hey, everybody. Here is our agenda today. We’ll start with introductions, move into our Native Integration topic, and then share a quick demo and wrap up with questions like Leslie mentioned.

So I’ll start by introducing myself. I’m Micah Bomsack. I’m the Workfront Subject Matter Expert for this session. I’ve been using Workfront since 2009. I started out as a creative, using Workfront as an art director, project manager, and as a system admin. I used Workfront as a customer in an agency setting, healthcare marketing, and retail marketing, so I’ve been in your shoes. I’ve been with Adobe for four years as a customer success architect, and I’m based out of St. Louis, Missouri. And I’ll let Warren introduce himself. Thanks, Micah. Hello, everyone. Warren Bartit. I’m an AEM subject matter expert, and I’ve been working with AEM since about 2014. Have worked with a number of Adobe customers on their implementations with AEM sites and assets and integrations that go along with that. I’ll be here today to help with some of the conversations and questions around the AEM side and any integration-specific topics that we want to go through. So happy to be a part of this today.

Okay, thanks for joining us today. We are excited to spend the next hour showing you how Workfront and AEM work together natively to supercharge your content operations.

This session is really about connecting the dots, how planning, creation, approval, and publishing can all flow seamlessly inside Adobe’s ecosystem. So we’ll walk through what the integration is, what value it delivers, how to set it up, and a few ways you can take it even further.

So what exactly is the native integration? It’s a direct built-in connection between Workfront and AEM assets as a cloud service. This means that teams can upload assets and send metadata from Workfront to AEM automatically. You can create linked folders and push approved assets right into your AEM dam without ever leaving Workfront. And because it’s native, it’s maintained by Adobe and it evolves right along with the Adobe Experience Cloud.

So here is where the magic happens. When Workfront and AEM talk natively, you can get consistency and speed. So first, projects move faster. No more emailing files or asking which version is final. Second, metadata stays in sync. So every asset carries the right campaign, product, or regional tags automatically. And third, setup is quick. It takes minutes, not weeks, and it scales beautifully across multiple brands or repositories.

And most importantly, it’s measurable. So you can reduce project life cycles, higher metadata accuracy, and far less administrative overhead.

So let’s talk about the problems this actually solves. When you have both Workfront and AEM without integration, teams can fall into Workfront and AEM silos. So you get duplicate data, broken approval chains, mismatched permissions, and tons of manual uploads. Over time, that creates tech debt, governance risk, and frustrated users. So the native integration wipes all that out. It gives you one consistent process, one metadata model, and a single source of truth for your assets.

For an enterprise already on AEM as a cloud service with Workfront and AEM assets, the integration is a great way to alleviate all these concerns.

So every good integration has guardrails, and it’s important to know them upfront.

So metadata flows one way from Workfront to AEM, so you’ll wanna manage accurate metadata in Workfront. Comments don’t sync, and each new version of a document creates a new version of that asset in AEM.

Also, if someone updates metadata in AEM later, it won’t flow back into Workfront. So those are just some things to understand and prepare for with the integration.

So before jumping in, there are a few boxes to check. The person configuring the integration needs appropriate admin rights in both Workfront and AEM, but end users simply need access to the folders they’ll sync.

Supported environments include AEM as a cloud service for assets, essentials customers, but not on-prem or managed services.

So make sure your teams are mapped correctly in the admin console and confirm that your metadata schemas in AEM are editable for the integration user.

For on-prem and managed service customers, Fusion can be used to integrate Workfront in AEM.

So planning is where most of the real work happens. Setting up the integration technically just takes minutes, but designing it takes a lot of thoughtful prep. So this phase is about understanding how your teams actually create, review, and publish content today, and deciding which steps you want Workfront and AEM to automate together.

Before changing a single key, make a configuration map your process with the goal being to document and visualize your current content supply chain flow on paper. Who starts a project? When do assets become final? Where do approvals happen? Decide your end goals. Maybe it’s automatic folder creation or metadata mapping or pushing approve assets to AEM for publishing. Just remember metadata flows one way and linked folders can be created automatically or manually. This is your chance to clean up the chaos and start with an efficient new workflow process.

And I’m gonna pause just for a minute. Oh, hold on a second. Here we go. Okay, here is an example of what a typical content supply chain flow looks like. So this isn’t the only way, but it’s pretty common. So there’s a lot here. You start with content planning and alignment. From there, teams create briefs and assign resources and work front.

Creative work happens, assets are reviewed, and once approved, the final versions land in AEM with all the right metadata.

The yellow boxes show where the integration kicks in through intake and creation and then storage and management. So I’ll pause here just for a few seconds so that you can read through this workflow a little bit more closely. And then you’ll get this deck afterwards. So you can dig into it a little bit more than two.

Okay, so once your process is mapped, treat your rollout like you would any other implementation. Build a plan that includes change management, testing, communication, training, and support. Decide who owns a user enablement, who monitors early results, and when you’ll move from sandbox to production.

Once you save the integration settings, that integration is live instantly. So you want everyone trained and ready.

We recommend that customers test and work front sandboxes paired with an AEM dev instance. That’s the best way to validate before go live.

So now I’m gonna pass it over to Warren to talk about the preparation and the configuration.

Warren, do you wanna share your screen? Would you mind staying on it for now? Just because that’ll work. Yeah, that’ll work perfectly.

All right, just a second here to get this set up properly.

All right, so next comes preparation. This is where everything comes together. And as we go through this section and we’re going to walk through how to align metadata, set up linked folders, and connect workflows so that the systems actually start communicating in real time. But before that, let’s make sure that your metadata foundation is strong.

So it’s important to tailor this setup to what you actually want the integration to do. If your goal is metadata mapping, then make sure both systems already have those metadata fields created before you start. If your goal is linked folders, ensure those destination folders exist in AEM first. And if you want AEM smart tagging to enhance metadata, that needs to be, that feature and capability needs to be active at the folder level in AEM. Now we do say, integrations plural here. Within one work front instance, we can have multiple integrations to AEM instances. And we’ll show some of that when we get into our demo in just a bit here. All right, so step one, when it comes to metadata prep. And we need to decide what work front data needs to flow to AEM and where it should live once it gets there.

Now remember, work front is a system of record for project and campaign data. And AEM is where that data lives alongside your assets. You might push over campaign IDs, asset types, expiration dates, personalization attributes, whatever helps your downstream teams and systems understand an asset’s context.

Current best practices here are to really only send what’s useful downstream of AEM in the apps and for anyone using those assets downstream. And to not send some of the lower level work front specific metadata like task details and approver details.

After step one, the next step in metadata prep is to document on paper the mapping of work front data that needs to flow to AEM and where it should live once it gets there. What fields are you going to add the work front metadata to on the AEM side.

Work front, as we mentioned, is a clear system of record for project and campaign data. And that metadata will also live in AEM with the assets. As an example here, you might push over campaign IDs, asset types and expiration dates, as you can see in this table. Whatever helps your downstream teams understand an asset’s context, as we mentioned.

And again, best practice here, only send what’s useful in AEM and keep your creative metadata managed on the AEM side for anything that’s not capturing your intake forms on the work front side.

And so now after steps one and two, once you know what you are mapping, steps three and four are to check and double check to confirm that the field exists as expected, right, on the work front side and in AEM. So you can see there’s just preparation and planning that needs to occur to get your metadata mappings right prior to starting with the integration itself.

So in work front, we’re talking about native custom fields and in AEM, we’re talking about default and custom metadata schema fields. So just the work front native and custom fields, AEM metadata schema fields.

If you do need new fields on either side, right, now’s the time to create those. In work front, you can build your custom forms for things like campaign types or any new fields that are needed there. And in AEM, you can extend your existing metadata schema with the new fields, any drop downs, any line of text type of fields that you need there. And you’d use the normal metadata schema editor in AEM for that and ultimately deploy with your bundles. You wanna make sure though, as you’re doing this, that your fields are named consistently, right, and sectioned and grouped logically just as you would normally do in both of the systems because that always helps your creative and asset specialists with the metadata population process. When you’re applying metadata assets, makes it just easier for them to follow your standard and typical process for updating metadata schemas.

Now, after three and four, we go into step five, and that’s to confirm that our field types are compatible. And this is integration specific, right? The single line of text on the work front side maps right over to the single line of text on the AEM side. And we need to take care with fields like drop downs, multi-selects, tag values on the AEM side, just to make sure things are mapped appropriately and we have coordinating field types on those sides.

Now, when it comes to some of the more advanced scenarios, right, with things like drop downs, multi-selects, we have to focus a bit and spend some time on the field values themselves. So say it’s a drop down with seasons, fall, summer, winter, and spring, the values need to be equivalent on both sides for that particular drop down. Equivalent in the sense that they have to be spelled exactly the same, the values themselves, and they have to match in casing. The labels can be different, right? You could have, if you wouldn’t want to do this, but if the labels had different casing on the work front side versus AEM, but the labels have to match explicitly.

And with that, let’s talk about tags a little bit. It’s the same concept. Tags on the AEM side, if you’re familiar with those, they typically are, the values for those are a namespace and a path to the tag. So that value in that structure needs to exist on the work front side as well, if you want that tag to be populated appropriately on the AEM side. You can pick your tag values from AEM. Now, again, not the labels, but the tag values, that’s the most critical piece. And make sure those align on the work front side for any drop downs where you may be applying or intending to apply tags to AEM.

So at this point, we know that we have the metadata that we want to flow through the integration from work front to AEM in that direction. Before we continue to set up any of the linked folders, which would be next, it’s a good time to double check and triple check the rules of the integration. And we’ll step through each of these that you see up here on the screen pretty briefly. So one thing, when it comes to mapping fields from work front to AEM, you can map one work front field to one AEM field, that’s pretty obvious. And you can map multiple work front fields.

So you can map multiple fields on the work front side to those same equivalent fields on the AEM side. But what you can’t do is you can’t have multiple work front fields going to a single AEM field. As you can imagine there, multiple fields trying to write to the, multiple work front fields trying to write to the same AEM field can be a problem. But what we can do is take one work front field, say an expiration date field on the work front side and apply that to multiple AEM fields. If you’re familiar in AEM, there’s the expires and there’s the off time that are very often the same value. So we can take the one expiration date field from work front and apply that to both of those AEM fields. But only that way, one work front field to multiple AEM.

Now the metadata schemas on the AEM side obviously must exist before we can configure the integration and the custom fields, I’m sorry, the metadata schemes on AEM side must exist before we configure the integration. And on the work front side, the custom form fields, right? They must exist as well. Cause when we go through the integration, it’s going to look up the existing fields. So we have to have those in place. Now some additional metadata recommendations. These are common things that aren’t specific to the integration, but when doing this integration, you want to make sure you are adhering to best practices here. So some obvious things with reserved characters and namespaces on the AEM side, no change or uniqueness here, but you want to make sure that your best practices for metadata on both sides are in place and being used here. Now the last comment here is when you are updating metadata from work front to AEM, the metadata is going to get overwritten on the AEM side. So if there is, you see an existing asset and we are pushing a new version of that asset from work front to AEM, the metadata will get overwritten. There will be a new version of the asset, right? In AEM, but the metadata will get replaced. So anything that’s part of the integration that is specifically and explicitly mapped in the integration will get overwritten. Other fields that exist in AEM, those won’t get touched, but anything that’s mapped, the assumption here is that the source is work front. We’re pushing the asset and its metadata so that will win on that side from the work front point of view.

And so let’s talk about linked folders.

So linked folders provide you the ability to push assets that are in specific folders in work front to specific folders on the AEM side with some automation there without having to manually set things up. And they can also be used to create folders on the AEM side in a predefined and prescribed structure, folder structure. So this step here is essential for keeping your asset management just organized and efficient. First, keep your AEM folder names under a hundred characters that’s always important. And as we know, most special characters get removed and you should use clear and simple names that align to your file and folder naming conventions.

To be able to write to the folders on the AEM side, the users that are in work front, their accounts in your admin console, they need to have right access to the parent folder. Otherwise the integration can’t sync those folders. Now linked folders are only added when a work front project is created.

If you have a project that’s already existing and you update an integration that’s, work front to AEM integration that’s applied to that project and change the link folders, that won’t take effect on the existing projects that are associated with that integration. It only kicks in for new projects.

And something to keep in mind here when thinking about the number of link folders that you set up, the integration is limited to 100, right? And that’s per integration and we’ll show what we mean by per integration.

But that’s a very large number, it’s unlikely that you would go beyond that, but just do keep that in mind that 100 folders is a max per integration.

And there is a caveat here for work front proofs. The integration can certainly be used for documents added to projects, have enough for proofs themselves. The actual documents that are right and on the left rail click on documents, the ones that show up there that are not proofs can be sent across in the integration. For proofs they can be certainly moved over to AEM and with those you want to use Fusion for that. The native integration can support documents versus proofs.

Just keeping these guard rails in mind, headaches as your team and your just asset library grows. Following these ensure that the integration is scalable, reliable and easy to leverage.

And last parts on the linked folder concept. When setting up link folders, keep those guard rails in mind. All it’s, the 100 folder limit is important. The folders in the folder tree as we discussed, they do have their limits.

And just lastly on this, you always want to follow a best practice. When going through these types of integration and working with different systems and the best practice here is you don’t want more than a thousand images per folder. That’s a typical work front best practice, a thousand items, it’d be a thousand items in a dropdown or a thousand fields in certain places. A thousand is a good indicator for an upper limit on the best practices here. So just keep that in mind as you add assets to work front that are intended for the integration, a thousand is the limit there.

All right, so now let’s actually see what the integration looks like. What it looks like to configure an integration and what effect it has. So when we start this demo, what we’ll do is we’ll go through the process of creating an integration. I’ll walk through the different steps, what each of the options means. And then we’ll go through a pre-existing integration that’s already stood up as mentioned. The integrations don’t, changes to the integrations don’t apply to existing projects. So we’ve staged a project and an integration and we’ll show what it’s like to push an asset with its metadata over to AEM.

The context for this demo is typical content supply chain flow using work front as your intake source and your task management for your workflow. And from there, we go into the review and approval process and we’ll start right at the point that we’re ready to send assets over to AEM. So I’ll share my screen here.

All right.

Hopefully you can see my screen.

Yes, look at the screen. You can see my screen? Oh, perfect. Excellent. Yeah. All right. So we’re looking at a work front instance here. I have three tabs open. I have a project in work front. It’s already established. I have templates. We’ll look at that quickly. And I have AEM assets. We’ll go to each one, but let’s go look at the actual integration setup steps here. So I’m going to go to set up in work front and I’ll go down to documents. I’m already there and I’ll click on experience manager assets and I’ll filter this down to our active ones. So we have an active one here and we’ll go through the process of creating a new integration.

So Micah mentioned, right? It takes minutes, not weeks, right? So once you have your mappings on, on documented on paper and you know what needs to be added here it really is quick and intuitive to establish the integration. Now, the first thing we need to do is give our integration a name. I’ll give it to something like this. And you can see here, the URL to AEM is already established. So based on your admin console or in your product associations, you’ll have different AEM instances here. So as you pick the different ones, this URL on the navigation side will change.

And from there, we go down to our metadata. So we talked a lot about the mappings. So what does that actually look like? How do we do it? It’s right here. It’s pretty straightforward. So here I can search for different custom fields, more front. So let’s say I wanna do a campaign ID.

So I can select campaign ID at the different levels that it’s applicable. So I can do it, pick the one at the project level, request or template, going to go with project here. And here on the AEM side, it’s doing the same thing. It’s actually looking at the metadata schema that’s appropriate for the AEM instance that we’re bound to here. So I want campaign ID on this side.

And you can see I have, let’s see, a few campaign ID options that exist.

Let’s see. We’ll take these purposes, should be in the custom. We’ll go with the XDM campaign ID there. And we can add other fields. I mentioned expiration dates. We can grab dates at date fields. We have an AEM expiration date here and expiration date here. And something to keep in mind is this integration won’t do that effort to align the field types for you here. It’s making the assumption that you’ve done that pre-work upfront in your mapping and in your preparation exercise so that you know specifically which fields to grab and that those fields, the fields on the AEM side are compatible with the work front fields as well. So this is how we add the fields here. And once we have our fields added, this option automates the syncing of that metadata. When this is not enabled, the integration will still push assets, but it won’t push metadata.

Continuing on here, we have the workflows option. And workflows in this context really automations that the workflow, that the integration can enable for us. So we can, I mentioned that on the AEM side, we can have the work front folders created automatically. And this is how we would do that. So I’ll click on create link folder here. I’ll give it just a name. So this is the name of the folder on the work front side within the project, within documents. So let’s say we have a final folder that we want created and this would be created when the project is created because this is associated with custom forms and project templates there. So here on the link folder route, you can see it’s opening up a dialogue that’s going to show me the AEM path of assets here. So I can pick anything here, select that folder. And so now this is the route in AEM. So this is where for any assets that are going to be pushed to AEM from any project that this integration is associated with, this will be the route. So what we don’t want to happen here is we don’t want everything to drop at a flat level, right? We need some type of additional structure to organize by effective project. So a few ways to do that here, we have our options here. We just enter the text of a folder name, something static, or we can use object data. Let’s say we’re doing say a fall campaign and it’s for the year 2025. We could simply select a project year and it’ll create a folder on the AEM side that is that project year 2025. And within that folder, we can have AEM say, say this is always for fall, for fall campaigns always, right? So we can add that here, I pulled it right in the fall.

Folder, and that adds the folder there. And we can add additional folder trees if we want to, as part of the integration, create multiple sets of folder hierarchies.

We do have the link and unlink option by default. This icon here represents the fact that this is a linked folder to the work front side. We can remove that by doing the remove link option here, and we can always add it back here. And again, any changes here only take effect for new projects created based off of this integration.

The publish assets automatically option, this one used with care certainly, because what this does is exactly what it says from the AEM point of view, is when you push assets with this option on, they get published to the activation target or targets that you select here based off of your implementation at different options here. So we can choose to do that, but again, take care with that. And here for linked folders, we can establish just a singular path for these linked folders versus creating that hierarchy that we just created a little bit earlier. So we can do the same thing. We can pick a folder here and have that set. And we can, if we wanted to, we can leverage this default option to append the portfolio and our programming from work front to those linked folders.

So this is how we set up the integration. And two things I wanna call out before moving on from this. One, you see this is an integration for this AEM instance. So that’s one option if we need another integration for another AEM instance that is configured to interact with this work front, Sandbox’s work front environment.

We can add those, but also within a single connection between work front and one AEM author, we can have multiple integrations there as well. So we have different needs for mappings. Say we’re pushing assets into a different set of folders in AEM that leverage a different metadata schema. We can do that here as well. So we can add multiple integrations, not just across AEM author instances, but within AEM author instances as well.

Right, so I’m not gonna save that. And we already have one established. I’ll just click on this quickly and show the settings that are in this one.

And that very similar, this one’s already bound to, and you can see this one’s already committed. So I don’t have the opportunity to change the AEM environment, not a common need to do that. I just wanna make that clear. I have a couple of metadata fields mapped here, campaign ID and agency of record. One is a text field and one is a dropdown.

And we’re syncing metadata and we’re not doing any linked folders for this purpose. All right, so let’s look at a project here. First, let’s look at a simple template before we go to the project.

I do want to go to the managed one here.

Refresh.

Just wanna show what the template looks like, just a normal template, nothing unique or atypical about it. Just a standard template on the work front side. Just wanna make that clear that nothing extraordinary is needed when setting up this integration.

Let’s see, finding the one that I wanted there.

Try to scroll a bit to get to it. Yeah, just a standard template, right? This is a typical asset production project template with tasks defined and nothing is extraordinary about this template. We can leverage any template that we have for this integration. And if you’re using request queues that get converted to projects, all of that still works. Nothing extraordinary is needed on that side. I do want to show what’s configured in AEM before we send some assets over to it. So let’s go look over here. So now we’re looking at AEM author. So I’m already within the metadata schema forms area. That’s obviously accessible through the toolbox item here, assets, and then metadata schemas.

And once in here, we can just normal AEM metadata schema management, edit any of our default or customers. I have a customer here, a very simple one. And I’ve created a new tab, a custom tab here, campaign data. And I’ve added the campaign ID field, which is mapped to a campaign ID property. And I have an agency of record field, which is agency. If you recall in the integration, these are the two properties that are mapped in that specific integration.

Now let’s go to my project somewhere. I have one already established here.

And let’s see.

Can I pick the right one here? I believe this is the right one.

All right, so now we have, this project is in flight, right? It’s a project with some tasks completed and the next task is compliance, legal approval. Of course these tasks would be filtered right in normal work front scenario. I’m the admin of this project, so I’m seeing all the tasks, but if these were assigned to different people, we’d be at this step, compliance, legal, final approval.

So here, just for the sake of our demo here, I’ll just add a couple of documents to this project. Of course, when typically doing this, you would have these already established, but I’ll add some just for our demo here.

Had we gone through the full content supply chain flow, we’d be at a point where we’re just reviewing and approving these assets. Let’s get these staged. And then we’ll push these over to AEM and see the metadata there.

A couple more here.

And once these are done, I’ll click on project details so we can see the metadata associated with this project.

And when we were doing that mapping, when I picked different metadata fields on the work front side, I had the choice to pick something, pick metadata fields from the project level, from the task level.

I chose the project level, so if you had needs to sync metadata from a task point of view, you could do that as well. But here we’re at the project level, so I’ll go to the project details and just have some custom metadata here, that campaign ID and just an agency record, Adobe digital. So now let’s go to our documents here. And I’m just going to push these over really quickly. So now I’m selecting the documents. There are several ways based off of the options that are available that we saw to get these assets into AEM. One, if we had Blink folder set up, we have folders here on the work front side, we could drop the assets in there manually or through automation to get them into that folder at the right time within our workflow, and that would automatically push them over. Also, when we need more flexibility, we can choose the integration here that we want to push these assets in the metadata to. So I’ll choose, I’ll go this route here. It’s going to ask me, hey, where do I want to drop them? Because if you recall in my integration, I didn’t specify which folder, so I want that flexibility here. And I’ll just drop this, so we do have one already in there, so we can see the version added.

And so these three assets are being sent over to AEM.

And in real time, you can see the update and the status there.

Let’s go over to AEM and go look at our folder.

Right? Here we have our campaigns folder.

And we can see that the assets have been added in the processing, which lets us know they were just added here.

So they’re very easy to set up, very easy to execute against D-Ray, and with several options. There are just a few options in that integration configuration area, but they’re pretty powerful. Each option serves a very specific purpose and gives you a lot of flexibility to configure each of your integrations with AEM here. And you can see processing is occurring. So the normal post-processing that occurs on the AEM side, which would include things like smart tags, anything that any workflows that you have on the AEM side, all of that takes effect, and none of that is blocked by the integration in any way. I’ll just go to properties on this.

And I have my campaign data tab, and you can see that metadata that was applied is there. I have my dropdown with, I have my default for this dropdown field, but Adobe Digital was applied appropriately. And now we have our metadata from Workfront added to AEM.

And that rounds out our demo of what we can do here, that the integration is very flexible in that you can set several options that can align your specific needs for your content supply chain workflow to help you get these assets, get this metadata into AEM, remove steps from your process, and improve your overall content velocity.

And with that, I’ll stop sharing here. And I think it might be a good time for us to go into a Q&A. Yeah, absolutely. I know you had marked a couple of questions in your slide. Did you want to talk about those first before we open it up? Sure, yeah. So there’s some common questions that come up when talking about the integration. One is, can metadata sync both ways? Another is, does this replace AssetLink? And another is, can you use this with AEM managed services? I’ll go in that order. So can metadata sync both ways? No, it’s unidirectional, right? From Workfront to AEM. Of course, metadata can come back from AEM to Workfront with the use of Fusion. But the native integration itself is that one way acceleration for you is to go in very quickly from Workfront to AEM. And does this replace AssetLink? No, in no way does it replace AssetLink. Using AssetLink being the capability from Photoshop, InDesign, Illustrator to push assets from those creative tools, desktop tools themselves directly to AEM, that AssetLink still works. It’s just an alternate approach for getting assets into AEM. So considerations for your overall flow need to be kept in mind there. Nothing different there.

The integration doesn’t change that approach or the decision needed there. It just makes it easier if the decision is to have your assets in Workfront before getting them into AEM. Can you use this with AEM managed services or on-prem? No, this is specific to cloud.

So works with assets essentials and just AEM assets as a cloud service, but it is not available for many services or on-prem.

Awesome.

We flagged a couple of questions that came through in the chat. I see someone with their hand up. I wanna ask this one first because I think this is a good one to touch overall. It sounds like from everything you’ve said, preparation is kind of the key. You need to sit down, look at things, map them out, do all that thinking ahead of time, and it’s gonna be a lot of work in the long run. So with that said, what would you say if you wanted to average ballpark, how much time if you’re thinking about implementing this, how much time should you plan for that prepping period? Yeah, that’s a great question. And I have to caveat it with some assumptions, right? Because for this to work, for the integration to work, you have to have your metadata and your taxonomies for assets overall, right? Whether they be in Workfront, whether they be in AEM, you have to have that taxonomy defined. So let’s assume that there is an acceptable taxonomy already established.

And if that’s in place and your content supply chain workflow is already defined and established in Workfront and other tools that may be in the mix there, then just planning the integration, then planning out the mapping of metadata fields per integration, right? So let’s say it’s a unique integration for an asset type, for a specific asset type like design guides, right? Something like that.

That’s about a week’s worth of effort for the first one. Of course, things, there’s an economy of scale, right? Once you get the first one completed, it becomes quite a bit easier because you have your templates, now you’re just repopulating based off of the same exercises for say different asset types. But that first one is about a week. And that it’s a week in that that gives you the opportunity to socialize, to validate, to talk to other teams who may be using the taxonomy, confirm that the taxonomy is still accurate. So about a week is what we see. It could take longer just depending on how complex your needs are for that mapping. If you’re mapping 75 metadata fields, right? It’s gonna certainly take longer than if you’re mapping 15, right? It’s not common to map 75, but as an example, there may be use cases where that is valid, depending on what you’re doing with your supply chain. Great question. Yeah.

Is the usual workflow to use proof, document approval, and then pushing that approved document to AEM? I would say yes on the workflow with the most important part being that final piece, that approved document to AEM. Of course, the integration doesn’t stop you in any way. If you have use cases and scenarios where you need work in progress files in AEM for your purposes and it’s part of your workflow, you can absolutely do that. You can link WIP folders from Workfront to AEM, all that’ll work great. But most often and most commonly, this integration helps with, or is focused on final approved assets. Because we’re in Workfront, we’re going through our content supply chain workflow, we get to the end of that flow, and that’s when we want our final assets moved over to DAM, and then anything that happens downstream, any other activations that may occur.

So key point there being the approved assets, so like the way it was phrased, just want to make that clear. And then to the first part of it with, proofing happened happening before, yes, absolutely. You wouldn’t really want to, it’s not common to send assets over to AEM until that proofing process has been completed.

Awesome.

This is a trickier question, but I’m going to ask it, and if we have to come back to it, that’s okay. But as a second part to that question, they were asking, how are folks dealing with approving interactive documents like PDF forms, given that it’s not necessarily supported in proof? That’s an excellent question, Mike. I’ll ask, do you want to take a stab at that? I have an opinion, but I think we may have to come back with some additional. We may have to come back to that one. Interactive, anything video related or web-based is in a transitional period with that approval process. We’re redoing all the document and proofing approvals into a unified approval experience. So it’s a little bit in process right now. So I don’t know if we have a good answer for that right now. The plan is to be able to address that to where we can move that over into AEM when needed. But right now it’s not really part of that integration right away.

One of those stay tuned. Stay tuned, yeah. Yeah, definitely. And for anything that doesn’t work with the native integration, so it’s important to understand, the native integration and Fusion can co-exist, no issue there, right? It’s up to, you don’t want to repeat the same functionality on that initial push to AEM, but Fusion, right now all the capabilities that exist there are still available when Fusion is part of your set of tools.

Awesome. I’m gonna try and take a couple of live ones. Elikim, do you wanna try and come off mute? Hey everybody.

I got a quick one, actually a number, but I’ll allow this to go as well. So when we did this in the past, we had some issues. One of which was that it did not support AEM metadata fields that are namespaced with the prefix DC column, right? So DC title and some of those other DC fields.

The other one that we struggled with was a multivalued, any multivalued metadata field in, on the AEM side, right? How that gets mapped from Workfront to AEM, let’s say for a tag field, for example, that’s separated by columns and such. Just wondering are those issues now solved or supported or? Great question. On the DC, that one still, it requires some workarounds, right? That would be sending the metadata to a sort of interstitial field on the AEM side as an option and then having an AEM workflow or a job, whichever is appropriate for that scenario to map that over to the DC field. But the good news is on the multi-select that is functioning as intended, right? Just an hour test and for quite some time now, the multi-selects do work. They work with tags, they work with dropdowns. So that’s good news there. Okay. The other one was date fields. As you know, AEM has a very specific format for date fields, out of box date fields. How does that work with the integration? Yeah, it works very well as long as you’re mapping date field to date field. So like that expires example, if we use the expiration date fields from a Workfront native expiration date field on the Workfront side, which is a date field, that will work. We tried to take a string or a single line of text field and even if we had the exact right format, the string format on the Workfront side, that wouldn’t work because it is that object that is expected in the integration. But date fields will work just fine, it is date to date. Gotcha. One last one and then maybe I’ll see it to somebody else.

Which AEM metadata fields show up in the Workfront Connector? I’m talking about the touch UI type fields versus the new assets essentials in a face type field. There are different things.

Which fields show up on the Workfront Connector? Certainly the touch UI. So if you wanted to, well, when you’re editing metadata on the AEM side, not the form itself, not how they’re presented and the structure, if you’re actually adding a field or for some reason changing a property name, not a common thing, but if you needed to do something like that, you would do that with the touch UI. You can’t do that in the assets field, at least not today. So the fields that you’re looking at in the integration when we’re selecting our field from the AEM side on the right side of that two column area, you’re looking at the fields from the touch UI. That’s a great point. Yep, in assets view, we do have the ability to create different forms for our metadata specialist, anyone who’s applying metadata to leverage, we can actually edit the properties themselves there. So it is anything that you’re looking at in Workfront during the configuration of the integration is sourced from the admin view slash touch UI. Yeah, Jim. So when we’re doing implementation for clients, we should be doing this all in touch UI, or should we be implementing the new assets? Yeah, you should, yes, yes and yes. You should be using that. I totally understand the question too, but you should be using the touch UI for your set of your fields. If you need new fields, you need some changes, something right now is a single select, you need to change it to a new property, that’s a multi-select, that type of thing you absolutely do in the touch UI. Of course, with the understanding that once that’s established based on your practices and approaches, you may want to move that change after it’s done in the UI to your code bundle.

But all that done on the UI, and when it comes to consuming the metadata, when someone needs to actually go see what metadata there is on an asset, to do searching and to just actually be a consumer of the asset and its metadata on the AEM side, assets view is a great way to do that.

So it’s configuration, touch UI for sure, of the metadata schema fields, but consumption, you can use either one, but assets view has a few more features.

Okay, thank you.

All right, I’m gonna share a couple updates real quick, and then if we have a second, we’ll come back to answer another question or two if we can.

Couple updates I wanted to share with this crowd, the Adobe Experience Maker Awards the deadline has been extended. In particular, this conductor category has to do with using Workfront and AEM. So wanted to call that out. If you have something you want to submit, you’ve got a little bit longer. I mean, those awards are announced, finalists are announced in January.

And then I’m gonna drop that link in the chat real quick.

So that’s the Experience Makers Awards. We are doing a survey for our programming. We wanna learn more about you and what you wanna learn and how best we can support you on your Workfront journey. So there’s two surveys in the chat. Cynthia dropped one about today’s event. That one’s super quick. It’s anonymous unless you add information about if you’d like to be a speaker, but otherwise it’s completely anonymous. Helps us plan our programming. And then this survey that I dropped in is a longer survey. To help with our planning for next year.

And then just wanted to talk real quick about upcoming events.

October 28th to 30th is Adobe Max. This is in person and online. It is free to register online. So if you wanna catch some of those sessions that this is the big creativity conference, I figure that could be relevant to this crowd here. So you may wanna check that out. We have a whole slew of free events coming up. October into November, those are all on experience league, Adobe experience league on the events page. And then I also wanted to call it if any of you are in Chicago, Cynthia, Nicole and I are hosting a lunch and learn in the Adobe office for Workfronters. So we would love to see you there. So if you would like to come make sure you register so we can ensure access and order lunches and all that good stuff. So I think that’s all I have on my end. Looks like we have three more minutes. So I know Gerald, do you have your hand up? Would you like to ask your question? Yeah, thanks so much. So, hey, Micah, this is Gerald from Gore. It’s one letter we know that Micah’s our CSA on some project work and she was a tremendous help.

We have recently launched our release with Workfront our revision. So my question is this, I’ll try to make it quick. So the scenario is we’ve got requesters who have projects in Workfront and the project is to update multiple documents or assets, each asset having its own kind of unique metadata. So how does that work with? So if you’re trying to pass assets from Workfront into AEM but let’s just say it’s like an asset ID like a business ID value, would it be unique for each asset, right? So like do you have direction on how that kind of a scenario could play out? Cause it’s not practical to have them open a new project for each document they want to update necessarily. So if they’re saying like, hey, I got to update 10 of these right now instead of doing 10 requests, is it, you have any ideas or suggestions that could be or point me in a direction that’d be great? Yeah, if the business ID is a field that you have like a custom field in Workfront, you could put that whatever unique ID that happens to be, if that’s filled in to that field, you can sync that as like custom field to custom field in AEM.

As far as like, if a lot of the fields are different for each asset, that’s something where we kind of, we’re talking about enriched metadata.

What you’d want to kind of push from Workfront to AEM is the main meat of things like, what program it’s in, maybe the project or specific Workfront information. But then if you needed to add those specific details on each asset separately, it’s kind of better to do that on the AEM side of things to add more of those tags and more of that metadata that’s like specific to each individual asset.

But does that help or does that cover what you’re talking about? It does, that’s kind of the direction that we’re heading in but I was hoping that there was something that we missed and that you, but yeah, this is good, thank you. Yeah, and adding in on the AEM side, enriching that metadata with extra tags is really easy to do in bulk. You can put it on a whole folder, you can put it on different assets just by selecting them quickly. So it’s a little bit easier to manage that metadata where it’s been pushed over from Workfront.

So in the request, would they be sending us, let’s say a spreadsheet with all of those assets, specific variations of metadata. So like, how do we get that source detail then? So if we go in and enrich the metadata manually in an AEM kind of content management step, like we still need to get the metadata from them. So it’d probably be an attached document, I’m assuming. Yeah, that could work and you can do a bulk upload there. Not sure if it would be helpful, but you could map the document ID from Workfront to AEM, but it sounds like you have other metadata as well that you would need to send over. So yeah, as Micah said, if it’s asset specific, you’re better off managing that on the AEM side once it gets over. Thank you, I appreciate that as well. Using some of the bulk. Perfect. Thank you. Yeah.

So we’re at time here, guys. I know we still have some unanswered questions. I’ve gathered those in a document. We’ll work with the team to see if we can get those answered and either, depending on how quickly, either show them in the follow-up email or we’ll be posting this in Experience League and we can share a Q&A after the fact and get that answered. But thank you all for your time today. Keep an eye on your email, keep an eye on the Experience League community, and we’ll share some more information there. Have a great day. Thank you, Micah and Warren, for sharing all this awesome info. And we’ll see you all. And thanks, Jen, for answering questions in the chat. Yes. Thank you, Jen. All right, everybody, have a great day.

Bye. Thank you.