51黑料不打烊

Transcript

Okay, so to start, I鈥檓 going to be over here on my, in fact, I鈥檒l just stretch this for now. Over here in my AEM environment, I鈥檝e gone to my Workfront Experience Manager configuration, Workfront for Experience Manager. Again, just to walk through that, tools, cloud services, the Workfront for Experience Manager. And this is, again, when the connector has been installed in your AEM environment, and then we can open the properties here. So when I say the advanced tools, there are some system or global, is a better way to put it, some global settings that can be configured here in this Advanced tab. So we鈥檝e talked about the Event Subs tab. And there are some advanced settings that do rely on event subscriptions. So just beware, and I鈥檒l call those out as we go through them. And then we spent most of last time talking about project link folders. So sort of to wrap things up, as far as the configuration dialog is concerned, is this last Advanced tab here. So we鈥檙e just going to go through these one by one, and I鈥檒l talk about them. Some of these will actually require a quick demonstration, whereas others will just actually talk at a high level as to what they do. So the first one, pretty straightforward. I don鈥檛 think this needs much of an explanation. To provide some context here, and why we need this checkbox is because AEM is a cloud service, or 51黑料不打烊 Experience Manager assets as a cloud service, sites as a cloud service, whatever flavor of 51黑料不打烊 Experience Manager you鈥檙e using, does require or does have some different APIs available to it. So if you鈥檙e using an on premise version of AEM, there are certain APIs that you would use for, let鈥檚 say, uploading and deleting a document. So there鈥檚 certain APIs that you would that are supported on on premise versions that may not have the same support as a cloud service. And the reason for that is really just the difference in architecture. So if you鈥檝e attended any trainings or done any training on cloud service, one of the things that makes 51黑料不打烊 Experience Manager as a cloud service unique is its binary list replication. So I鈥檒l just briefly explain that right. The asset binaries are actually stored in your cloud service environment. They are stored in an Azure blob storage, which means that every asset that you see in this AEM environment, you鈥檙e just seeing a reference to this asset that鈥檚 being fetched from an Azure blob store. So it鈥檚 stored in Azure. So it鈥檚 all binary list replication, and you鈥檒l hear that word. So because of that, it sort of has some there are some nuances in cloud service with how the APIs work. So really, at the end of the day, this checkbox sort of takes you on a different route in the code to allow you to leverage the right APIs for 51黑料不打烊 Experience Manager as a cloud service. So that鈥檚 really the goal here. So you鈥檒l see mine鈥檚 unchecked. I鈥檓 demoing right now in my own local environment. So I don鈥檛 have this checked. So just be aware of this if you鈥檙e working with a customer that鈥檚 ams or an on prem solution of deployment flavor of am this checkbox is not necessary, you can leave this unchecked. However, if you are going to deploy this in a cloud service environment, we do need to check this and that just tells the code, which API is to use and which ones not to use. So these next two that you鈥檒l see checked in my environment, these are fairly commonly or these are these are commonly used by the customers that I鈥檝e worked with in the connector. Let鈥檚 talk about this first one here. So store assets with the same name as versions of the existing asset. Pretty straightforward, very, you know, easy to understand here. But the idea is that any asset that鈥檚 pushed inside of a link folder, so I鈥檒l do a quick demonstration of this one. Let me just pull this our demo project up from last time. So we have this demo project from our previous call. Let鈥檚 say I have an asset here in the final files folder. If I came and grabbed that same asset. And I were to upload it into ams, let me make sure I grabbed the right one is the asset. Because this checkmark, this checkbox is selected, this asset is going to get stored as a version of the existing asset that was already linked. There is something just to call out here. This is just a the way that the UI in Workfront works. But when I refresh, it may take a second depends really on your connection speed. You鈥檒l see like a duplicate asset there for a moment. But once this is finished processing, these merge into a single asset. So this asset down here will will merge into this asset here. So there鈥檒l be a single asset, there won鈥檛 be two assets there. So that just sometimes takes a moment in terms of the time that it takes to process the asset. But if we jump over to am in the meantime, and we go to that file, we鈥檙e going to see that a single asset exists here. So when I actually drag that, you鈥檒l see down here that just a minute ago, this asset, there鈥檚 now a new version of that asset. So if I select the asset here, and I were to go or actually, let鈥檚 click on more details. And then look at the asset timeline, I can select the version history. And you鈥檒l see that a new version was added a minute ago. So that was that version that I just dragged in. And then eventually Workfront will catch up here and those assets will be merged into a single version as it pulls it in. There you go. So now we just have the single asset. So that was all because this checkbox was selected. If a customer doesn鈥檛 want assets diversion, we have had this and that鈥檚 why we made it a configurable option. If they don鈥檛 want to create a version of an asset with the same name, then they could leave that unchecked and every asset would just be its own static asset. So we do have customers sometimes who prefer to have a static version saved without using a versioning feature. It鈥檚 not something we recommend. But if the client, you know, sees that there鈥檚 a value on their side for storing these assets separately and maybe they add a different version number to the file name. That鈥檚 why we have this as flexibility there. The second one is pretty straightforward. This is again, if you version an asset, and you have this selected, so in that motion where I drag the asset in and I created a new version, if we check this box, it will update the metadata if it鈥檚 changed since the first version was uploaded. So the other day when we uploaded this first version here, if the metadata on the document custom form had changed, or if the project metadata had changed in between, you know, when it was originally uploaded to AM and now it鈥檚 going to update the metadata quarterly with the new version. Again, that鈥檚 an optional configuration because what we鈥檝e learned with a few of our larger customers is that they want they don鈥檛 necessarily want to update the metadata. When a new version is created, they may want to keep that the same. So I would say that more often than not, our customers are checking this box. But we do have several customers who do not want to update the metadata. So that鈥檚 why we do have it as an optional configuration. The next one is just very straightforward. AM does change special characters. So if an asset has a special character, an asterisk or question mark or a dash or a forward slash or something like that in it, AM has a tool that has the assets being ingested, it will remove the special characters and add an underscore, for example. This one, you can change that so that when there鈥檚 spaces in the folder name, it does add a dash as opposed to an underscore in the name. So there are ways to just ensure that you have the right folder structure. Very specific use case, I believe for two of our clients where they had a pretty hard requirement around the naming convention of their folders. And then the set metadata folder types in accordance with Workfront. This is specific for when those project link folders that we talked about the other day. So there are information icons for all of these, but this is just it鈥檚 really when we鈥檙e applying metadata to AM folders that they follow the right format. So this would make sure that the data types at the folder level, so we talked about folder metadata schemas on the last call, that the data types are set up accordingly for when you create a linked folder. So meaning that we鈥檙e passing that project ID as an example to the folder and using the correct data type so that we can use it for other processes. This is one of those features that I will say in practice is not leveraged by a lot of our customers. I believe one, maybe even two of them uses this today. But that鈥檚 why it鈥檚 here in the connector. And that鈥檚 why you see it. So there鈥檚 the explanation for that. But I don鈥檛 anticipate this being something that most customers will use. These next two sections automatically publish assets. So this requires a bit of an explanation on AMs publishing workflows and AM architecture in general. So if you鈥檙e not as familiar with AM architecture, there is a author and a publish, and then even a dispatcher environment for almost every AM deployment flavor. The idea of author is that鈥檚 where content is curated, edited. That鈥檚 where you鈥檙e if you鈥檙e using AM sites and assets in conjunction, that鈥檚 where the pages are built. That鈥檚 where assets are uploaded. Metadata is edited. But many AM assets customers use it in conjunction with, let鈥檚 say, AM sites or some asset share commons is a very, you know, commonly used feature for publishing assets. So let鈥檚 say that a customer has an asset share commons instance, and they鈥檙e hosting sort of a share library that鈥檚 customized and branded for their own, you know, business needs. This allows us for when an asset is being pushed from Workfront to AM to automatically publish. So what we鈥檙e doing here is that any asset that鈥檚 uploaded to AM through the Workfront connector can be automatically published if we check this box. And then we can also add a condition statement. So the condition statement could be AM published. So is, you know, do we want to publish this asset? You may have a custom form filled at the project level that says, do you want to publish the asset share commons? You know, and if it says yes, then we would publish this asset. So just to give you more flexibility around when assets should be published and when they shouldn鈥檛. So maybe that custom form filled in Workfront is an admin only section. So we only give the Workfront user the ability to go to that admin only section and check yes, publish to, you know, asset share commons. Once they do that, and then push the assets, then everything will automatically appear in the published instance of AM. So the next three down here, these are these two, well, I鈥檓 not going to, I鈥檓 going to hide this one, this is a develop environment that I鈥檓 showing you, as I mentioned, so please ignore the second option in this here, we鈥檙e just going to talk about the document updates, document update events. And that the idea here is that you do have to subscribe to event subscriptions for that feature to work. As I mentioned, there鈥檚 a couple of features in here that require event subs to be enabled. And this is one of them. So when I select the subscribe to document update events, what that does is it creates a new update event subscription at the document level. So it begins listening for updates at the document level. And then that will list. So if I鈥檓 in again to walk through that, if I鈥檓 over here, since this setting is saved, I open this document custom form. If I were to edit any of the field here, and I have this checked, modify the description here, AM is listening for those changes. And if I save this, because of that event subscription that we created at the document level, AM will update that field accordingly. So if I come back to the asset here, I should see here at the document level, that description that I just made. So the ability for AM to listen to changes at the document level in Workfront, or what allow so that checkbox is what allows for this. So I could come in here and change this again, AM is going to update accordingly. We have this publish all project assets to the brand portal upon completion. So this is very similar to this one above minus the condition statement. So again, just some, you know, inside baseball on AM, there are multiple ways in which you鈥檒l see AM implementations using a brand portal or asset share library type feature. The more commonly used one is brand portal because it鈥檚 something that鈥檚 being sold with cloud service and as sort of a standard package. So I may be misquoting here, but something like 500 user base users for brand portal out of the box with every cloud service package or something like that. So the idea is that any customer that鈥檚 purchasing AM assets as a cloud service is getting some, you know, license for a brand portal use and brand portal is a an 51黑料不打烊 owned service. It鈥檚 not hosted on, you know, a customer鈥檚 cloud service environment. It鈥檚 actually a separate shared 51黑料不打烊 service. So they have their brand portal servers that support this read-only experience. So it鈥檚 different in asset share commons in that it doesn鈥檛 have that full customized customizable interface that鈥檚 using AM sites, but rather just a integrated solution that can publish assets from your AM author environment to this 51黑料不打烊 shared service known as brand portal, where you can create read-only users that can go and share their assets. So it鈥檚 primarily used by marketing partners or third party design companies, or, you know, asset consumers partners of the business that will go to that brand portal to find content. It鈥檚 sometime even used internally as a share library as well, so that you have your only, you know, five or so damn admins that are in the author environment, and then you direct all your other users to the brand portal instance. So again, it just seems like a, when, as we were developing this feature, something that all of our customers were leveraging, a lot of our customers were leveraging was this brand portal. So this just gives them the ability to say, if the project completes, then publish all the assets in that project to the brand portal. So slightly different than this AM custom form condition statement, but rather if I were to come back to my project and I had these assets in here that were in the link folder, and that box were checked. If I change my status here in AM to complete that signals to AM. So again, that requires that this does require event subscription as well, because it鈥檚 listening for a project level update for the status to be complete. And once the status is complete, then those assets get published to brand portal. So this might be just a question of the verbiage that鈥檚 provided in those advanced settings, but the top one is referencing just an automatic publish in general versus the bottom one referencing brand portal explicitly. And in general doesn鈥檛 mean brand portal. This would mean only to a, if a client leverages a publish instance of AM as well for a publisher. That鈥檚 what I was trying to key into. So for instance, you couldn鈥檛, could you set up the same thing as a upon project completion for just the publish instance or the published here? Absolutely. Yeah. And the way that you would do it again, this is where custom forms are really like our best friend in the connector, because I can go in and say, I want a custom form field at the project level that calculates the status and updates the status accordingly. So you could have a custom form field that says when status equals, it would look something like project status, you know, custom form field project status, and then down here is CPL or something, whatever the value is in that complete field that the calculated field does. So you can mimic, and that鈥檚 why I just love using the custom form fields for a lot of these condition statements because you get a leverage out of the box work front functionality for the most part to create your conditions. So even though we just show one value and one condition, this calculated field could have 10 conditions built into it, but the output the AM is reading from that calculated field is just a single field. So you really, you see this and you may think, oh, well, I only have one custom field to work with and work front. Darn it. I don鈥檛 know if I鈥檓 going to be able to achieve this, you know, complex condition statement. Well then that鈥檚 where you say, okay, well calculated fields can do very complex condition statements. So why don鈥檛 I have a, if is then condition statement in my calculated field and I just have a Boolean response of yes or no based on that condition. Now I鈥檝e created a much more complex condition statement for publishing. Okay, well we鈥檒l jump into workflows. So I鈥檓 going to start first by demonstrating a workflow here. Again, I think I showed this briefly on the last call, but we鈥檙e going to start by a demonstration of that workflow again so you can see it. And then I鈥檓 going to walk through that first one. There鈥檚 going to be, hopefully given the time we have, I can get through maybe four of these advanced workflows and at least talk to the rest of them. But the first one that I want to talk to, but I鈥檓 just going to show you the one that I end up doing in almost every work front connector implementation is the attach custom form workflow. So I鈥檓 going to start here by grabbing a demo asset and just show this one more time. So I鈥檓 going to drag this asset again into my linked AM folder. Oh, oops, I have the project status complete. Sorry. Go back to current. Try that one more time. Okay. So now that I鈥檝e dragged this asset into my linked AM folder, not only is that asset binary going to be transferred over to AM, so again, not duplicating the asset in work front, but pushing this asset binary to AM here, I鈥檝e set up my AM environment to actually auto attach a document custom form to that asset and then automatically map some AM properties back to that custom form like the asset URL. So I鈥檝e changed some of those settings so we can actually do it together. So you can see how that works. But again, if I come and click on this asset that I just uploaded and select it, you鈥檒l see down here that there鈥檚 a custom form that automatically got attached right as I uploaded the asset, this document details custom form. So I can go to that custom form and you鈥檒l see here that I鈥檝e got some fields that are mapped here. Then now I can add and just like I showed moments ago, AM can listen for those changes now. So if I were to add a description, AM鈥檚 listening for those changes, but I also can push metadata bi-directionally. So I always want to be careful when I say bi-directional because what we learned initially was we don鈥檛 really want, at least our customers don鈥檛 really want true bi-directional syncing. And I may have explained this if I didn鈥檛, I鈥檒l just give you a high level. The reason we don鈥檛 want true bi-directional is because we need a source of truth. So the source of data becomes important. So what we figured out the best implementation strategy for bi-directional metadata was to make it configurable because we obviously heard from certain customers that being able to push metadata from AM was important to them. In fact, some customers even have their users uploading assets to AM directly and then just pushing back data to Workfront as opposed to uploading them into Workfront and having them push to AM. So we saw this need from our customers that was important, but we wanted to make sure that not everything is bi-directional by default. So if I were to upload an asset in AM and change the data, we don鈥檛 want it to automatically push to Workfront and same goes for Workfront AM. We may not want to do that for all data. So what we devised was this workflow step. So I鈥檓 going to show that here. So for those not familiar with AM, if you come up to the 51黑料不打烊 Experience Manager button, come down to Tools, Workflow, and then we have this Models here. This is where we build our workflow models using some of these steps. So here is the model that I built, and I鈥檓 going to use this to talk through some of the other steps that we have as well. But so this model here that I just am opening is the model that made this all possible. Attach this document details and then map back some AM fields. So first you鈥檒l see in my workflow model, I have these two steps and then a little bit of AM knowledge here again. Workflows are really simple to build. So if you just search Workfront here, that鈥檚 going to show you all the Workfront assets that come with this connector package. So we鈥檒l walk through a lot of these today and at least talk through most of them. But here I have this attach custom form step. So that鈥檚 the first step in my full workflow model. Here on this page, you鈥檒l see a description about what the step can do with some details. And then here are the arguments for this step. So we鈥檒l start with the first argument here, and that鈥檚 the type. So this is a very flexible model. It doesn鈥檛 just have to be a document custom form like you saw in my example here. You could do this with an object, a task or a project object, a task or an issue as well. So if you wanted to automatically attach a task custom form when an asset鈥檚 uploaded, you could do that. And you could automatically attach a project custom form once it鈥檚 uploaded. And there may be some required fields on that custom form and Workfront need to be populated when it鈥檚 automatically attached. So an example here would be, let鈥檚 say at a project level, once the assets are pushed AM, we want to auto attach a project custom form where it鈥檚 the responsibility of the project manager to go in and then fill out some special details on that project custom form about the asset maybe, or all the assets at that project level. And same could be done for a document as well, like we鈥檝e shown in this example, the task and issues. The next is the ID property. So we have screenshots and documentations on the ID properties here, but the ID property that it鈥檚 asking for, just to be clear is the object ID property that we鈥檙e storing in AM. So in this example, I鈥檓 looking at a document object. So my document object, you can find that in several places. So the ID property is stored up here in the URL. You鈥檒l also see it stored in a custom form field. So this is a calculated custom form field that鈥檚 pulling in my Workfront document ID into the custom form. But this is the same value that鈥檚 being stored in this property in AM. So if you鈥檙e not familiar with AM, the JCR repository or the Java content repository is what JCR stands for. The Java content repository repository is something that you鈥檒l probably never see in a cloud service environment unless you鈥檙e an engineer. But just to help everybody understand where that what I鈥檓 talking about when I say dot slash content Workfront ID, that refers to the actually property title in my AM environment. So let me actually just go here. So this is the screen that you hopefully never have to ever see. This is something that our engineers will use in their local development environments to troubleshoot and look at different files. But when I look at a metadata property, so I鈥檓 going this is like the back end of going into the dam. And we鈥檙e going to look at one of these assets here and that I pushed. In the final files folder, here鈥檚 that asset that I鈥檝e pushed. Actually, let鈥檚 look at this one here. I鈥檒l extend this and then zoom in for you. So it鈥檚 a node based AM. JCR is a node based structure. So everything鈥檚 kind of, as you can see, organized in this folder structure for where all the content exists. And that鈥檒l help you understand the idea of why we have this dot slash. This dot sort of represents like everything in front of that path. So this is the end of the path. The path title is the property title is Workfront ID. And then this is stored in JCR content. So in the back end, what that looks like is this right here, that ID property, if everybody can see that on my screen. So the value that gets stored in this field, maybe I have to zoom out for a second. I can show you the value. So right there, that value Workfront ID, that is the value that I鈥檓 pushing when the asset gets uploaded to AM. So I have this document ID value document ID value again can be found here in the URL. And then in AM we store it under this particular node feed JCR content node. And then that slash Workfront ID is the title of the property and it鈥檚 stored as a string. And there鈥檚 the value of my ID. You also see below it, I have a version ID as well. But this ID is important in our workflow model because we need to know what document object in Workfront we should attach that custom form to. So that鈥檚 what this workflow step defines is that ID property. What is the object ID that this custom form should get attached to in Workfront? So that鈥檚 the unique ID that it鈥檚 pulling. So it鈥檚 saying whatever stored in that property here, we鈥檙e going to push, we鈥檙e going to use that value and attach whatever custom form at the document level we want to attach. So in this case, I鈥檝e selected my document details. If I wanted to do multiple, I could use one of Mario鈥檚 custom forms here and I could attach multiple custom forms to a document in one push. Any questions around the first step in this workflow, the attached custom form workflow and how it works? So Adam, if you select something other than a document, so say you select project to attach the custom form, what you鈥檙e saying is that when an asset is uploaded to that document, you then attach the custom form to the project rather than the asset. If you attach multiple assets to the project, does that trigger each time and does it have some sort of condition that says if it already exists, then don鈥檛 attach it again? Yeah, that鈥檚 a great question. That will come in our launcher. A workflow model can stand alone without a launcher. It鈥檚 not necessary that you have a launcher set up for every workflow. What the launcher does is it automates it. So when I uploaded the asset to the project, we saw that it automatically attached to the custom form. But this so far, everything I鈥檓 setting up here in the model, the model can be ran independent of a launcher. So I could grab this, hit start workflow, select my payload, that payload is going to be one of my assets, right? And then just kick off that workflow. So to answer your question, yes, absolutely. We could set up a launcher and there鈥檚 condition statements within the launcher to say, oh, only attach it if whatever condition you want to add there. And those conditions are really flexible as well. So I鈥檒l make sure to kind of address that as we get to the launcher part. Brilliant. Thank you for that. The other thing that I鈥檒l call out here too in that example, so in the example of a project, excuse me, if we were to switch this to a project, this wouldn鈥檛 work well because we鈥檙e pointing to the document object, right? Because what I showed here, this is the document object that鈥檚 getting stored here. So we could absolutely attach it to a project, but what we鈥檇 want to do is point to some project metadata, the project object metadata field in AEM. So then we could say, well, there鈥檚 a custom field that I store. So if we鈥檒l go back to one of these assets, just as a reminder, I鈥檒l show you. Let鈥檚 say that when the folder gets created, we want to attach. So not on asset upload. Our condition is when the folder is created, we want to kick off that workflow after the folder is created and then attach a custom form. That way the right custom form gets attached prior to any assets being pushed. And that鈥檚 probably the more common example that you鈥檒l see is that when, you know, going back to Workfront, oops, going back to Workfront, when we changed the status and we get that link folder created here, that鈥檚 a good time to say automatically attach some project custom forms that may not be attached. So maybe there is a specific AEM assets project form that鈥檚 required. We don鈥檛 know it鈥檚 required until a folder gets created. So this is a project that, you know, somebody鈥檚 creating a project in AEM and they don鈥檛 necessarily need to push any con or sorry, someone鈥檚 creating a project in Workfront. They don鈥檛 necessarily need to push any content to AEM. So they may not create a link folder. So in that case, we could probably leave off the custom form. If they do and the folder gets created, that could be a trigger for AEM to create auto attach a project custom form. So if we look here at the folder properties, we mapped the project ID here. So this project ID could be whatever is stored here in this project ID. We could come in and let鈥檚 see if this works. We鈥檒l see that that same ID is stored here on the project level. So if we look for project ID, there it is, there鈥檚 our project ID. And you鈥檒l see here that that maps to the project ID over here. So that鈥檚 just another field. So when we鈥檙e setting up the workflow, we just want we have that flexibility here to be able to point it to a different value in AEM. So in that example, it鈥檚 the project ID is the way I鈥檓 storing this instead. So I鈥檓 storing this as a I come over here and I change my setup to be project ID. And then that鈥檚 going to pull the right object ID to attach a project custom form to so that I could select my business card project, whatever project custom form I want to attach. We also can pass the project ID to the asset level as well, right? That can be using a calculated field or the overview field. So like in this example, I think I鈥檝e done the same. So if we look at the asset properties, I am capturing that project ID here. But that just exists under a different property in AEM than the slash work front ID field, it would probably have its own unique value. So we would just that鈥檚 why this is so flexible, and that we can point it to different properties in AEM to grab the right object ID. I have a quick question. So how do we expect the work front users to know the AEM specifics, for example, the path of these attributes? Yeah, that鈥檚 a that鈥檚 a great question. And we don鈥檛, right? We don鈥檛. So our expectation with these advanced workflows and why we鈥檙e having this session with you is that these advanced workflows are something that an implementation partner, an approved 51黑料不打烊 implementation partner would assist the client in setting up. So advanced workflows are more of our advanced configuration steps. There鈥檚 a lot of things that you鈥檝e seen to the different training sessions that, you know, a work front admin may be able to set up on their own. But when it comes to these advanced workflows, that鈥檚 why we really call them advanced. They鈥檙e not something that we would say, All right, here you go set these up on your own. There鈥檚 something that requires some guidance and some oversight to set up. Thank you. So the next step in this model is the map property step. So we saw here that we attach this document custom form again, let鈥檚 just go to that. Now, what if we want to push back some attributes when the custom form gets attached? Let鈥檚 go through and actually configure some of those. So this map property step is the our bi directional configuration option. So bi directional, but bi directional only by choice. So the customer would have to actively choose to say, Yes, I want to push metadata from am to work front as well. And now they have the option to do add an individual field by field basis. So rather than saying, you know, carte blanche, everything is bi directional, it鈥檚 a, you choose which fields you鈥檇 want to push back. And what we found is that鈥檚 much cleaner implementation approach, because then they can really be specific about what am properties are important to have in work front. And there鈥檚 a lot of them that they don鈥檛 need in work front. So we don鈥檛 necessarily want to say everything鈥檚 bi directional, you just decide if there鈥檚 a generate a system generated am property, let鈥檚 say a smart tag, for example, or somebody goes in and applies a tag and you want those tags to also be pushed back to work front. A common one is an expiration date. There鈥檚 a lot of am assets customers that I work with, they utilize digital rights management, or the digital rights management features of am. And let鈥檚 say that they have a systematic process in am that applies an expiration date based on their upload date. So every six months, these assets require a review cycle. So if an asset needs to go through a review cycle, that may get added in am automatically as a part of their digital rights management workflows. So maybe that鈥檚 important that we push a field like that back to work front so that a work front user can run reports on assets that are about to come up for review, right. So there are a lot of these examples, I think that become really important to the customers on being able to have that flexibility and sending back data. So in this example here, I鈥檓 going to do a really basic one. This is going to be the Let鈥檚 see, set this one up with a am author URL, let鈥檚 do another one too. So what you鈥檒l see here in this example is, again, I have that ID property, just like in my previous step. So it says, Okay, what document object am I attaching this to? So first, it says, again, what document object am I attaching the custom form to? Great. Now, which document object is it the same document object, presumably, but that may not always be the case. But here we define it again, well, what document object Am I attaching the metadata to? So first, the form second, the metadata. So I can come in and add as many fields as I鈥檇 like. And the syntax here works in that it鈥檚 a custom form field, because if it鈥檚 an out of the box field, we don鈥檛 have the same luxury of being able to update some of the like system generated fields. So when I say system generated, if I鈥檓 looking at, like the project level details, a lot of these overview fields that are sort of critical in a lot of the functionality, right, like projected start dates, all this stuff, we don鈥檛 give the ability to modify those fields, but rather just what you鈥檇 find in a custom form field here. So when you see de, this is sort of work front standard text mode syntax, de just means that鈥檚 a custom form field and work front. So if I鈥檓 looking at project initiative, or better yet, let鈥檚 do this, let鈥檚 stick with the document. So if I鈥檓 looking here at the document, and we see am author URL or asset description, you know, I could come in here, let鈥檚 do asset description, as the description equals, and then after the equals, we can point to an existing am value. So again, this is how you format a custom form field in work front. So this is the text mode, that鈥檚 pointing to this asset description field here. And then the next after the equals is what value in a em do you want to send back. So that鈥檚 where this kind of, it鈥檚 important, at least at a high level understand the JCR structure. So when we see dot slash JCR, colon content, we can point to an existing am field. So the description. So that field there that I鈥檓 just pointed to, is referencing this field here on the basic tab, the description field. So if I were to say, this is a test. And we were to just look at this asset in the back end, so I can show you. We see that DC description, this is a test. So what I鈥檓 really doing is I鈥檓 saying, taking in this large JSON, I鈥檓 taking first this JCR content node. So first this JCR content. Then next I鈥檓 taking the metadata node, and then specifically the property name, which is DC description. And then I鈥檓 pushing whatever value is in that field back. So this is the test. So if I come look at this, it鈥檚 going to look at the asset that I鈥檓 running this workflow on, because workflows are ran on a specific payload. That payload may be multiple assets. So it may run across the series of assets. So it鈥檚 going to say, OK, if you鈥檙e running it on this particular asset, in that example, it鈥檚 going to push over this is a test inside this asset description field. So that鈥檚 what I鈥檓 defining here. Now there鈥檚 some more flexibility here, but you can also just push back a static string. So say you wanted to append some value, so like am, say something like this. We do a static string in quotations. We鈥檇 say am value equals. And then, or no, I think I did that syntax wrong. I think it鈥檚 plus path. I think it鈥檚 plus path. So what that will do here is it鈥檚 going to do a static string for every value called am value, and then it鈥檚 going to take the actual value that鈥檚 in this field in am and push it back to this custom form field and workflow. So let鈥檚 keep this one simple for now. We won鈥檛 do this concatenated string. Let鈥檚 just do this one description field here. So it鈥檚 going to take the value that鈥檚 in here. The other thing, I should have called this out earlier, but if you come back and look at the custom form field, again, it鈥檚 important to look at the form field name, not the actual label. So in Workfront, when you鈥檙e looking at custom form fields, so this is the custom form field that we had attached to that document. If I come and look at the asset description here, we want to make sure that we use the name, not the label, because this right here is pointing towards the name through the APIs. So the APIs are exposing that value as the name, not the label, just an important distinction to make here. So in this situation, they鈥檙e the same, but sometimes you鈥檒l see something like this or asset description am, and then they have a different label. That鈥檚 just greater flexibility. And that鈥檚 a fairly recent Workfront change, I think within the last year or so, but a really great change because it now gives you the ability to have a user-friendly name, a user-friendly label for all your custom form fields, but then have a unique name for each of those fields as well. So I really like this feature, but it鈥檚 just something to be aware of and cautious of when you鈥檙e pushing metadata back. So with that, I could hit check, sync this workflow, and then if I were to come over to this asset here, there鈥檚 a couple ways to trigger a workflow. If you鈥檙e viewing the asset in this asset details pane, you can come over here to versions, and then down here at the bottom of my screen, you鈥檒l see this little carrot. If I select that, I can start a workflow from here and find that model. So I could attach custom form and map properties and start that workflow. That鈥檚 one way you can start a workflow. Another way you can start a workflow is back on this screen. You could come in and just select, hit create, workflow, again, find that same form and hit start. So that鈥檚 sort of the manual, which I would say in the example that I鈥檓 showing here, that鈥檚 not what I would do and not what I would set up for the customer because that requires that somebody in AAM goes and manually triggers the workflow. So here鈥檚 where I want to introduce this concept of launchers. So you see triggering that workflow populated the asset description. So again, if I came in here and just modified that property and then triggered the workflow again, and then trigger that workflow, it鈥檚 going to update that field. See how fast it did it here. There it is updated description. So that鈥檚 the workflow. That鈥檚 the first step. The second step is automating that so that whenever something changes on this asset, we automatically update it in AAM, making this truly automated bi-directional thinking. So the way we do that is leveraging workflow launchers. So again, if I come to the tools, go to workflow, come over here to launchers, are we expecting our Workfront users to know how to do all this? Absolutely not because it鈥檚 not that varied baseline, send an asset and some metadata from Workfront to AAM. This is the tool for the larger enterprises are utilizing today for a lot of their advanced requirements. And not to say that this couldn鈥檛 be for mid-market clients as well that have some more advanced requirements, but it鈥檚 enhanced in the sense that it does require some expert configuration knowledge and knowing the nuances of AAM and Workfront together. So Workfront launchers can be tied to any workflow. So in that example, I鈥檓 just going to pull up the launcher that I have created here. I have this launcher that says, anything underneath. So first it starts with the event type. Is this a modified event type, a create or removed? So in this example, we鈥檙e just changing metadata values. So I select modified. So event type is tied to a node and the node is, could be an asset, a folder, anything. All of these are considered nodes in AAM and each node can have properties associated with it. So I鈥檓 pointing to this node type dam asset. You see that if I click on this, this is considered a dam asset node type. So if I click here, you鈥檒l see the primary type of this. So again, this is a little bit of AAM knowledge here, but this primary type dam colon asset means that this node that I鈥檓 clicking on is a dam asset. So that鈥檚 why in this property, I select dam asset. So if the dam asset has been modified and if it exists under this specific path slash content slash dam slash Workfront. So this is important because it doesn鈥檛 run. This workflow won鈥檛 trigger if the asset lives in any other directory in your repository. And then you can select, well, does this happen on the author environment only? And we talked sort of about the difference between publish and author, but you could select, you know, this workflow should run if it鈥檚 on the publish environment as well, but we鈥檙e just going to select author cause that鈥檚 really the only AAM author and connect the Workfront connector or the only integrations here. There鈥檚 sort of indirect relationships to the publisher given some of those advanced workflows that we talked through. But for the most part, this is just with the author. And then here鈥檚 where we have our condition statements. So this requires a little bit of understanding of AAM syntax or their query language. So how to build queries and conditions within AAM. So it鈥檚 SQL two, JCR SQL two is the syntax. So again, this does require a little bit of a technical knowledge on setting these up. So if they have an AAM implementation team or there鈥檚 an AAM partner, they can help with the right condition statements. But what this condition statement saying is as long as the description field is populated. So first does the asset live under, is this an asset? Does it live under this path? Has it been modified and does it meet this condition statement, which is, is the description field populated? You could even say only do it if the description field equals a certain value. If you only want this to run once and not three times every time an asset鈥檚 added, you could add a condition statement to really ensure that this is only running absolutely when it needs to run or it was only kicking off only when it needs to. So you can get really flexible. I鈥檝e seen condition state like five different condition statements applied to a single workflow launcher. And then the next step is it is selecting the workflow that you want to run. So then we have this attached work front document, custom form workflow, and we activate it. So upon activating it, that鈥檚 what actually will trigger this workflow. Yeah. So that鈥檚 what actually going to trigger this workflow to go off when I make a change on the asset level. So when I go back to the asset, well, now I鈥檝e lost it. That鈥檚 where we get that automatic kicking off the workflow. So if there鈥檚 a change to it, you鈥檒l see here, like when I uploaded the asset for the first time, we saw that that document custom form auto attached. And if I come to my timeline window and select one of these assets, we can see that this was started automatically. So when I uploaded it, this workflow started automatically because the asset was modified. So I can add multiple launchers to trigger at different times and under different conditions.