Workfront custom forms and metadata mapping

Transcript

The topic today is going to be metadata and the world of metadata and work front. This is more often referred to as custom form fields. So I’m going to probably use those terms interchangeably throughout this demonstration today. So if you hear me say custom form fields, I’m likely talking about the feature and functionalities on the work front side. If I say metadata schemas, I’m likely talking about metadata in AEM or any of the properties that you can find in the properties tab of an asset within AEM. And what features we built in the connector to map them. So that’s really going to be the goal of today’s call is to walk through all things metadata. So in order to do that, what I found most useful is first talk about each of those features sort of independently to start. Over here on, let me make this window bigger for a moment. Over here on this window, I have my work front environment pulled up and I’m going to talk specifically about custom forms and work front first. And the reason I start here is that in most cases, now this isn’t always the case, but in most customers implementations, work front becomes sort of the source or the initial collection of metadata. So the story I often tell here is that from ideation to delivery is what the connector really provides. It provides that bridge between our work management tool and where our assets are stored. So really I think of work front is the tool where we’re starting to collect data from ideation. Let’s say a specific team has been assigned to develop assets for a campaign and it’s really all the way at the request of a work front project. So let’s say an internal team, or maybe it’s a, we have customers that have request cues that are submitted by external partners as well. So let’s say that it starts as a request and work front, a request for some digital content. We’ll keep this simple and say, we’re, we have a new winter campaign and we need to develop some new images for our website. So a request has been entered in work front. And really that’s the beginning of where this conversation about metadata begins is all the way at the request. Now that’s not always the case. We have some customers who use work front that don’t really leverage request cues as much. They’ll typically start at a project. So they may be capturing project custom form fields as a part of their initial project template, or they add additional fields as it sort of moves through the project life cycle. But again, I’m just going to start from requests. So I have an example here in our environment where you may submit a new request. You have several options in here. So we have a contract request and these are all the custom form fields we built in work front. So all of this data can be captured when we push assets from work front to AEM. So that’s why I like to start this conversation in work front. So here’s an example of one of the requests that we use at hoodoo to submit new contracts. So let’s say that’s a likely scenario for our customers is that we want to be able to store our contracts in the dam. So they’re easy to find. We can add metadata to them. So if we need to look back at historic contracts and see the terms of that contract, we can do it there. So this request gets submitted and those requests are built in work front’s custom form field editor. So again, if I come up to the nine box grid here in work front and then I come over to set up again, if this is all assumes that I may, I’ve been given the proper privileges within my work front environment to be able to build custom forms. And then you’ll see over here on the left, I have this area for custom forms. So this is sort of the work front equivalent of what you would see in AEM when you go to the tools menu and come down to assets and you look at the metadata schemas either for folders or assets. So we do support both folders and asset mapping. So here over in AEM, this is where we build our custom schemas. And then over here in work front, this is where you build the custom forms for all your different work front objects. So when you’re building a new custom form in work front, you build that form for a specific object type. So when I say object type, project, task, request, issue, document, portfolio, so all of these different forms I build will only be available for that individual project or object. So if I built a custom form, I’d have to build a project one if I wanted to be able to leverage it in a project. In the previous example where I had that contract request form, I’d have to build this as a request. So I’d have this request form. And then the important thing to note here is that work front has this concept of resolving object types or resolving objects. So what that means in the work front world is that if something started as a request or also known as an issue, and it had a form as a part of that request to fill out with some custom details that were required for the requester, you would have to make an equivalent project custom form that had similar custom form fields in order to resolve that object to a project. So resolving the object would be the motion of converting the request to an actual project. So in the work front world, there’s most times a traffic coordinator of sorts who’s responsible for managing the request queues. And assuming that there’s resources available and all the work has been done to get resources for that request and everything’s been finalized, then they can convert that request to a project. And if that project they convert it to, if they use a project template, that project template needs to have a corresponding custom form that has similar custom form fields, or it may not have all of them, maybe not all of them are needed for the project, but at least all the ones that you’d want to maintain throughout the lifecycle of a request being converted to a project need to also exist at the project level. So that’s something I know that’s not right now I’m talking a lot about work front specific stuff, but as I thought about today’s presentation, it’s important to really understand the foundation of custom forms in work front prior to talking about the connector and how it maintains the metadata back and forth. So again, I could select a project and then begin creating a project custom form and add custom form fields and give us a title and then I can come in here and drag and drop different custom form fields. So this could be a single text, single open text, but again, a lot of the fields that you see here have equivalent fields in AEM. So if I have a single line text field here, I have a single line text field. I could make the single line text field a multi-field instead in work front. So I could use a dropdown or a checkbox would be another example. So if I drag the dropdown onto here, you can allow more than one option to be selected. So that would be the equivalent of a multi-value text field here or a dropdown field here. So I will share some of the things that our team has learned about to make this mapping easier because it’s not always the case that mapping up the field type is the best. And where that comes in, I’m making a note here to talk about that later, but tagging in AEM, so uppercase tags in AEM, as we talked about tagging taxonomies, this is something that we found to be one of those situations where mapping the exact field may not be the most efficient, but we’ll talk more about that later in the demonstration. So for now, just to keep it simple, any fields that are built here, once this custom form is saved, and then we come in here and we open up the metadata schema editor in AEM. So if I click on title, you’ll see once the connector has been installed, you have this new option down here for each of your fields where you can map it to an equivalent Workfront field. So if I select the dropdown, this actually shows me all of the custom form fields and irrespective of object type. So even though in the work front environment, we create custom forms for a specific object type, so a project custom form, a task custom form, AEM doesn’t really care because what it’s going to do is whatever object contains a value in these mapped fields, it’s going to pull it over. So for example, if I come in here and say document ID, if the asset and work front that gets pushed to AEM has a document ID, which in this case it often does because that’s a required work front field or a systematic work front field, it will pull it over and add it to this field here in AEM. Only when there isn’t actually a value present in the custom form field in the work front. Any questions so far on that piece before I dive into some more of the nuances here? Are there situations where potentially there’s some embedded metadata that comes across as part of the asset and you try to map to it with a work front custom form field and there’s like a battle there between the already existing value that the asset has and what you’re trying to map into it from work front? Yeah, yeah, that’s a good point. And in fact, there are some fields in AEM that are immutable, right? So there’s some systematic fields. Let’s say when you upload an asset to AEM, it goes through what’s referred to as the dam update asset workflow. And during that workflow process, there are some systematic fields like who uploaded this, when was it uploaded? They aren’t actually editable. So in those situations, if we’re trying to map to one of those fields and how we would do that would be like type. Type is an example here where the DC format is a systematic field that gets extracted as a part of that dam update asset workflow in AEM. So this says whether this is a PDF, is this a JPEG, is this whatever file type that is. If we try to overwrite that field, nothing will happen to that field. So there are sort of like immutable fields that are systematic, where even if we do map to it, so in this situation, if we map to it, we won’t be overriding it. But there are other fields that we could incorrectly map. I hope I’m answering your question, James, so correct me if I’m not, but there are these sort of systematic fields that AEM may already assign a value to that we want to be careful that we’re not like overriding as well. Right. Yeah, and that makes sense. Just to be clear, the mapping utility will still exist, so you could potentially do that overwrite. You just need to know if the customer is wanting that information there, you’d have to be very privy to what AEM is trying to prescribe for that. Right, right. And then the only other thing I would add to that is that I know in most of these cloud environments and customer environments, you’re not going to have access to CRX, but this is more of just AEM knowledge that there are certain fields that even though you can map to them, AEM won’t have the ability to update them. It’s like when you come down here to these fields here in the JCR in AEM, you’ll see some of these fields are uneditable, even if I’m in the back end trying to change the created by date, it’s not going to let me. So there are some AEM fields that even if you map to, AEM just doesn’t allow you to change them. And that’s like the created by, uploaded by, created date, the JCR UUID. There’s just certain fields in AEM that even if you see that there’s an ability to map to them, you’re not going to be able to override them. But those are mostly all, in all cases, systematic fields. Oops. Does that make sense? Yep. Thanks for the clarification. Perfect. And I have a question like we created a form on the left hand side. Can we check for that on AEM? Can we see the same on Adobe demo? No, so not the whole form. Again here, if I were, let’s just go through this process. So let’s say I want to create a new project form. So we’ll actually do one. So let’s say here we’re going to do an Adobe demo project form. If I were to add just, let’s keep this simple. We’ll just add a single line text field. And then let’s add, let’s say like a radio button. And let’s just say yes or no for our options here. So let’s say these are both required. So this could get added to a project in Workfront. It could be included as a part of a project template in Workfront. So that way, anytime a project is created using that template, this form becomes standard as a part of that. And these fields are required. So when I save this, if I refresh AEM now, because it’s during the initial opening, so the call is made to pull in all those metadata fields that exist in your linked Workfront environment, a call is being made. And it’s pulling all those options into the dropdown. So it’s not really looking for the form itself. AEM doesn’t care what form they belong to, because it doesn’t really matter. We’re not looking for forms. We’re specifically looking for, again, here on my left, the fields that are a part of the form. And AEM doesn’t really care at the end of the day what form and Workfront they belong to or what object type they belong to. All that we really care about in AEM is that if that field is on a Workfront object that you are sending an asset to AEM from. So if I’m on a project and I send an asset from that project to AEM, does this field exist? And is there a value in that field? So in that case, I could come over here and let’s say I have this project details. So I’m going to come and create an equivalent field here. So this is the, if we go back, let me try to get this right. So if I type and grab that project field I just created.

So again, I have these two fields, so I’m going to just equivalent here. I’m not feeling creative today, so I apologize. I’m not getting too creative with my names, but here’s my single line text field. So this field is going to be mapped to this field here. And then again, and this is more just general AEM knowledge, this map to property, make sure that this gets changed to unique property or it’s just going to, everything’s going to overwrite that default property. So we give this a unique name. I always recommend doing some kind of camel case here, something like this or some concatenated version of it. But then that will be the name of the property that we’re storing the value in. You can add a placeholder, but that’s not required. And then down here, this is where we’ll search for this field that was just added. So if I come down here and I go single line text, now this field in AEM is mapped to whatever values in this field in Workfront. So then I can do that again with a radio button. So if we come down here and do- And the name is identifier, like the name is unique. You cannot create another field with the same name in Workfront site? On the Workfront site, they actually have some flexibility there. So yes, the name has to be unique and it’s required, but you can get flexible with a label. So our connector really only cares about the name. So your name does have to be unique, but the label doesn’t need to be unique. You could have 20 of the same labels, same label, but you do have to have a unique name. And that’s what we’re mapping in AEM. And can you reuse fields between different forms? Absolutely. Yep, absolutely. So there is in Workfront, there’s a field library. So again, the fields are sort of created separately so that you can reuse them across forms. So- And if I want to use that on every form in my enterprise, I put that in a template? Yeah, ideally, yes. You’d put it in a project template, like on Workfront site. And that all depends on the customer’s implementation of Workfront. I have some customers that they have a unique fields for every project template. I have other customers where they have sort of their like general project details, custom form, that’s a part of every project, but that really does just come down to the individual Workfront users’ implementation of Workfront.

So I’ll come over here and add another single line text. So here’s an example of where I’m not matching my field type. So the field type in Workfront is a radio button. And radio button right is a yes or no. You can’t have both. It’s not a multi-select field. So since there’s not an equivalent radio button in AEM, all we need is a single line text, because this is just going to send over a string value of whatever the option they selected was. So the JSON that gets sent during our connectors call will send over either yes or no, depending on what they selected and store it. And that gets passed over as a string. And then we can store it in a single line text field. So we’d come and we’d call this one Adobe radio button, and then give this unique name.

And then I can map it to that Adobe radio button field.

And then I, so now if I were to have saved these, and we’ll show this in a moment in the demo, so I’ll actually go ahead and save this now. Actually, I’m going to wait and talk through some of these, but that’s an example of where the field type isn’t necessarily need to match. Again, it’s really, think of these more as, are you sending over a string? Are you sending over a Boolean? Are you sending over a date? Are you sending over some different type of format? Like, is it not a string? If so, then you may need to use something else. So if I were to create a field that’s like a date, right? So I come in and grab this date. Well, date’s not going to send it over in just a string format. Date’s going to send it over in a date format.

So in that case, we would want to include a unique date field. So we’d say, okay, let’s use the date property here to map the dates.

But you’ll notice, right, since I haven’t saved this new field, Adobe Date, if I come down here and try to do my mapping, we’re not going to see Adobe Date.

No matching results, because really, I have to come in here and save this first, which would mean I have to save this so that I get those other two options. And then when I come to edit this now, then it makes that call. So when I open that alert, then makes the call and pulls in any new fields that were added during that time. So then if I come down here and open that project again, I should be able to find the Adobe Date.

There we go.

Does that all make sense? How really it’s that if you’re adding new fields and you have the editor open, you’re not going to see those new fields. It’s not like the screen is making requests all the time to get the new fields. You have to reopen the metadata scheme editor in AEM to pull in the latest changes.

I had one question just on a, potentially a particular customer use case, but say a customer wants to be able to update that metadata on the AEM side. And so for things like a radio button or a dropdown, where it’s very prescriptive and you want it to have verification of a value instead of just a user in AEM typing in a yes, no, in this case for that text field, how have you typically handled that? Or is that a common ask? No, it’s a very common ask. And I think if you’re okay, I’m just going to bunt it for a moment and then I’ll come back to it in the context of tags. Before I answer it, make sure I understand what you’re asking clearly, is if it were, let’s say a radio button here, and I want to be able to make it a, give the customer the ability to change that radio button in AEM as well. Well, if I just do what I did here, then that’s not really going to work, right? Because it’s only taking whatever values and work from it. So somebody would have to come in and manually add yes or no, which isn’t great because we want options so that they select the right thing. Because if yes or no are the only options they should be selecting, well then an open text field is not going to really meet the requirement. It would be better for us to do something like a dropdown and we do.

Right, and then we’d go, okay, here’s our Adobe radio button.

And we’d say yes or no, right? For our values, so we add two choices and we’d say, yes.

No, no. And then in that case, it would still work. This would still work. And I would say to answer your question more from a business specific requirement standpoint, because we could map this to the Adobe radio button example.

This is more often deployed when we let people, when we, and I shouldn’t say let, but we strongly advise against metadata not having a single point of truth for metadata. And you can imagine some of the complications that that presents. If we open up editing capabilities in both Workfront and AEM for metadata, then there’s no real source of truth for that metadata. And that’s really important, right? In a good assets implementation, we need to identify what is the source of truth for metadata? Is that Workfront or is that AEM? And what we’ve learned is there is a gray area. Yes, ideally, if they’re pushing assets from Workfront to AEM then I would say Workfront should be the source of truth for data. The asset originated in Workfront, you captured all your metadata there. Let’s push it over to AEM. And Workfront should maintain, should be that place to update metadata. It’s the source of truth. If we have implementations where really you can update any of the fields, whether they’re in Workfront or AEM, then it becomes hard knowing like, what is the source of truth? Which field should we trust? If there’s a discrepancy where Workfront says no, AEM says yes, what data should we rely on? So from a process standpoint, this becomes something that we really try to drive home in our implementations that you should identify your source of truth, at least for most fields. So the gray area comes in, in the event that there is data that you’re capturing in AEM that you’re not capturing in Workfront. And we try to keep those limited. There shouldn’t be a lot of those. They should be kind of some of the system fields, smart tagging is a great example, right? Workfront’s not gonna do any smart tagging of your assets. So it’s not until the asset gets uploaded to AEM that you might get some smart tags added to it. So those are some of those gray areas that we’re okay with having sort of this like, well, most of the fields source of truth are Workfront, but there may be some of them that AEM is where, you know, the actual data originates, if that makes sense. But again, just to stress that we’ve seen implementations that can go sideways if you have folks that are going into AEM and making metadata changes, and now you have discrepancies within Workfront, or you can, and we’ll talk about this in a later scheduled training that we have, advanced workflows, we have created a way to sync the data back and forth. So it is bi-directional, but that bi-directional doesn’t happen inherently. And that’s for good reason, because not a lot of our customers want full bi-directional thinking of metadata. They want a source of truth. Most of their customers edit the metadata, most of that metadata is captured in Workfront, so we wanna rely on Workfront as that source of truth. So if there’s data that’s out of sync between the two environments, it’s probably because someone’s gone against process and gone into AEM and changed those fields. So again, it’s safe to say that in most cases, you wanna ensure that this is the source of truth here in Workfront. Whatever is in here should not be edited in AEM, but rather changed in Workfront so it flows down to AEM.

And to that end, you would just make those fields read only in AEM typically then. Exactly. Right? Yep, exactly.

So then you would, again, leverage just some of the out of the box tools where you come in here and you can say disable edit. So we’d say, this is a field that we’re disabling edit on. This is a field that we disable edit on. And then since we’re just going through the gray area here, let’s say for whatever reason, we do want this field.

We’ve kind of said to the customer, here’s the downsides to not using a source of truth for this data and having it editable in both instances, Workfront and AEM.

But if they’ve given a good enough reason and there’s reason to actually have it editable in AEM as well, then you could leave this one as editable and you’d have that ability to make a change. And then we could also set up, which we’ll talk about in a later demonstration, an advanced workflow that says, okay, well, if you do change it in AEM, let’s make sure that we pass back whatever value it gets changed to the Workfront custom form. So it is possible, but again, you could find yourself in a situation if you’re not careful that you have a hundred metadata fields and you have a workflow sending back metadata to Workfront for a change on any of those hundred fields. And that just may not be the best implementation, even though it is possible, it just may not be in the customer’s best interest.

Okay, so before I am gonna come back to tags and where we have some kind of nuances to discuss around data types, particularly I’ll talk about it in the vein of tags, but I think it applies to some other types too. But before I do that, I do wanna talk about these two buttons because they’re not necessarily clear. Both these buttons will become available and it’s important, I would say, and Mario, correct me if I’m wrong, but very few of our customers actually leverage these check boxes. They were built for a couple of customers and I see the generic value in having these features. And I imagine there won’t be, as this is released to the broader audience, there’s gonna be more customers that leverage this, but I would say that this is probably not a feature that’s gonna be leveraged by 80% of the customers, probably closer to 20 to 30%. So I’ll talk about the first one here, clear value in AEM when the value is empty and work front. So if I were to check this box on this field, the Adobe radio button, and I were to have this, so if I were, let’s save this real quick, where I cancel, I’m gonna come back to a project and walk through what this would actually look like. Let’s see if I have a test project here. Let’s see, sorry.

So I’m gonna just create a new project without a template, just standard. We’ll go Adobe demo. And let’s say I add that custom form.

So Adobe demo project custom form, I’m adding this to the project. Let’s say that I add this field. So I’m test, add a radio button, yes. And I add a date, save my changes. So I’ve had these fields populated. And then let’s say I send that asset to AEM. So I come in here, I upload an asset. Oops.

So if I upload this asset, the asset then gets pushed to AEM. It’s gonna pull that field that I had mapped.

Let me save these changes. So it pulled that field, or those three fields that I mapped here. And whatever value is in them at the time that I pushed, it’s gonna send that metadata value to AEM.

Make sense? So asset, that PDF gets pushed to AEM. I then get in that property that we mapped, I have a test value, a yes value, and the date value here. Let’s say that I then delete this, and this is blank. Well, this one wouldn’t be a good example because it’s required.

Let’s say I delete the date. So now the date’s not present.

And then I save my changes. So because I’ve now removed this, if I then send that asset a second time to AEM, so I come in and I drag that asset back in, if that property value has since been removed and now that value is blank, you can decide if you want to also delete the value in AEM so it’s also blank.

So what we found, and I know that’s a very specific use case to describe there, but what we found is that there are times when values get changed in Workfront for one reason or the other. They don’t necessarily want to clear that value from AEM when it’s blank. So if a date somehow inadvertently got removed from a project, like in this case here, so the date was originally there when the asset was sent, I’ve now sent a new version of that asset, the date’s removed. Well, if I check this, then it will clear out that value. But what we’ve learned from most of our customers is that in that example, if a date’s been removed and then a new version’s been sent, we don’t actually want to clear the value out in AEM. It was likely that this was removed inadvertently and we want to keep whatever value which was originally added to that field. So that’s an optional configuration. Again, we leave it unchecked by default, but in the event that there is a field that gets cleared out and we push an asset again, this would also clear out that field in AEM and remove it as well.

So then the next one here is get value from a Workfront referenced object field. Now, this is very unique to a specific type of field type in Workfront. So if I come back to the setup here in Workfront and let’s pull up that same project form that we were just working on, you’ll see that we have this, what’s it called again? Let’s forget the name of it, this type ahead field. Let’s grab this type ahead field. These are often used in Workfront when you need to populate like a user’s name or a specific project. So let’s say a real life example of this is that I have users that I need to assign to a project as a part of the custom form. So rather than let’s say assigning them to like a task in a Workfront project, but I want to be able to say, well, who’s the sales lead? We have a custom form for a new contract and we need to identify who the sales lead is for that contract. Rather than having like an open text field or maintaining a long list of dropdown items, what the type ahead field provides, so if we say sales lead, see here’s where it’s making me do a unique name. So I’m just gonna do sales lead dash one.

You can point to a referenced object. So this could be a user, a template, a team, project, client, any of these object categories inside your Workfront environment. So the most common use case is pointing to a user object. And that means that when I save this on a field, so I can make this a required field and save this. And then if I go back to that project that we had open, when we look at the details here, you’ll see I have this sales lead. And now it lets me select from a list of all of my Workfront users. So then I can begin typing my Workfront users and add them there.

So this checkbox again in AEM, get value from Workfront’s reference object field is very specific to that type of head field. It should really only be leveraged when you’re using that type of head field. And the reason is because those objects, when we send a value, so in the event that I have Brian Fulton here as my sales lead for this project, when I’m mapping that field, so if I come down, let’s just set this up here, let’s do a single line text, and we’ll call this one sales lead.

Give it a default name.

And then we’ll map it. I may have to, sorry, I apologize. I’m gonna have to, since the new field, I’m gonna have to jump out and then reopen it.

So I’ll come back here.

And then if I go to sales lead, I should have this as an option. And you’ll see sales lead dash one, the field. And then if I were to say get value from Workfront reference object, the reason I have to do this and then populate this line below is because when it sends the value to AEM, so if I have Brian Fulton here saved, and then I push this asset to AEM, so let’s say I select this asset that’s in here, and I send this asset to AEM.

Oops, waiting for these to load.

But I’ll talk through what’s happening here. You’ll see we have so many custom integrations in our environment. Sometimes that takes a long time to load, and that send to button doesn’t show up until they’ve all loaded. But now that they’ve loaded, I can come in here and I can do find my environment, and I can send this to AEM. So then it’s gonna grab those fields that I just mapped, right? Brian Fulton. And let’s see if I can show you an example of what it actually does initially when it sends that request.

So this is gonna give me the link to the asset in AEM.

Search it by the doc ID.

There it is.

So it’s still loading all of the, so I can’t look at the properties quite yet, but what you’re gonna see is that in that field that I created here, it sends a full JSON that includes many fields that are related to Brian. Because Brian, in this example, he’s not just a value. So the Brian Fulton value that I input here, he’s actually an object, and that object contains multiple values. So every user object in Workfront has the ability to attach their own custom forms and has a set of default values as well. So if I come over here to a user in Workfront, let’s select myself, you’ll see that my user, you can add a lot of custom information about my user. So in this example, I have even a custom form field attached to each user. So I have a Workfront user email in my custom form. I have a lot of information about my rates, my job role, all that information. So it’s not like it’s just sending a string value of my user’s name. It’s actually sending a full JSON of all the details about that specific user. So this reference Workfront object field is where I can specify what actual property within that user object I wanna map. So maybe I wanna keep it simple and just map email. That’s all I wanna map. So it’s the user’s email. So now I’m gonna actually pull in, in that JSON I’ll get this long JSON full of a bunch of values that are related to that specific user object, but I just wanna store the email of that user. So this field allows us to parse that JSON and only store a specific value that’s provided as a part of that payload.

I know that’s quite a bit for one small checkbox. So are there any questions on that piece? Yeah, so this is really useful, but I also know there are some cases where for that same user, we might wanna have a field contain their email and another field contain their full name. But I see a problem in AMS, it’s where if we have two metadata widgets pointing to the same property, it doesn’t really behave very well. So I don’t know if you’ve come across that or not. Yeah, you would just have to do something like this, right? This is what I would do. So I’d have simply email, but again, I’m mapping it to the same, got it, yeah, multiple values, right? So I’d have a different field name. Yeah, right, but it’s the same property that I map in Workfront. So these are mapped to the same properties, but they have unique field titles.

And then I would say name, right? So it looks something like that.

Okay. A quick question on that. So right there, you have reference to Workfront object field name. What if the name was another object? Could you go one level deep in the…

user object that was sent? Sure, like if it’s a second layer in a JSON? Yeah, yeah. Like you have a high level property in the JSON for name and then in it there’s first and last name. That’s a great question. Let me get back to you on that one. You stubbed me. So let me make a note and I’ll get back to you. I think that there is, I think the JSON’s actually like this, if I remember correctly, but I need to get a list of the actual JSON that gets sent from Workfront. I think it’s like that is more likely the case, but I’ll verify. That’s a great question. Yeah, thanks for explaining it so well. That’s why it created curiosity then. But nice, thanks. Good, I’m glad. Yeah. Of course. So we need to know the kind of the name stuff like elements in the JSON, right? To… That’s right. I’m gonna see if I actually can get one sent here. Sorry, I kind of did this on the fly. I’m not hopeful, but let’s see if it actually passes. Is the JSON exposed somewhere for the person to know without having backend access? It’s exposed in the Workfront API docs. What it will do is I understand it though, and I wonder if I can just make this happen here. If it is mapped, it should send it as a part of the…

It should send it anyways, and then it won’t do the full…

Okay.

I’ll try the tricky… If I can do it like this.

Anybody that’s new to AM, this is a tool I find indispensable, but tidy.infinity.

All right, so like we have ability to see what the payload is from here if I had a map correctly, ideally.

I have that saved. I may have not saved it the right way. But ideally it should push the entire JSON payload in order to test to make sure that we get the names, the property names in the payload correctly. But I’m gonna double check on that myself and then get back to James and he can spread the word.

Is that the only JSON that gets sent, the user profile, or are there other…

Any of these other objects. Yeah, so it’s not just the user, but if we look back at this type of headfield in the custom form itself, if we were to look at this custom form, there is a JSON payload that gets sent for any of the reference object types. So I just talked about user because I think that’s the most common. And again, this is…

But these are all the other ones. So like if you wanted to pull a company, it could pull several details about said company.

But these are all Workfront object types.

Well, I think, so that sort of sums up the metadata mapping and how it works. So again, just to quickly highlight a real life use case, right? Is that in Workfront, I’m gonna go back to that demo project, you can send assets with any of the objects. So I could send an asset in this case as a part of the project object. So I’m pushing this asset to AEM as a part of the project object. But let’s say I went into a task, I had a new task here.

And with that task, when I click into it, the tasks has a documents tab. So you could actually send that asset as a part of a task, which means that if there are details populated in the task, if I had a Workfront tools task custom form here, I could add details here. So if the asset were being pushed to AEM as a part of a task, it can grab the task details as well as the project details.

So in this case, if I were to push an asset to AEM and I’m using this method, so let’s say linked a folder to the task. In fact, while I’m waiting for that to load, I’ll just add a couple of details. So I added some of those fields there, some values in those fields. And then if I came in here and linked an existing folder, and then I uploaded an asset as a part of that linked folder, it would then come in and grab, assuming I’ve mapped those, it would then grab those values here, as well as any values that have a map that are part of the parent object, which is the project object. So any custom fields here. So really you see the value that I can pull tons of data based on the object type that I’m pushing the asset to AEM with. So if I’m pushing the asset as a part of a task, an issue, a project, not only can I pull it from that specific object type that I uploaded it as a part of, so if it were the task, I’m pulling the metadata from the task, as well as the parent object, assuming I’ve mapped the fields. So again, it’s important to know that it’s not pulling every custom form or every out of the box field that exists in Workfront. It’s only gonna pull the ones that are mapped to any of these referenced objects.

So just to confirm, the value in Workfront will override the value in AEM typically, and that happens when we open up the metadata editor in assets, right? That’s when it’s pulling the information from Workfront. Is that when that happens? Oh, so that’s for just setting up. So let me try to differentiate the two thoughts here is that I’ve covered both how to set up the mappings and that’s using the metadata schema editor. And yes, you’re right. And in that, if I go into the metadata schema editor and I add a new property or a new field, it’s not gonna show up in here until I open the metadata schema editor. So that’s more, your question, I think, is more directed to setting up. Yeah, I’m actually asking more about field values. Right, so field values, no. Field values is, let’s say I come in here to this project and I add the value, right? So I added a date, I save it. And then once those values are there, the motion of just pushing the asset goes and looks, what are the values that I’ve got stored in the fields that I have mapped already? Oh, okay, so when the asset is pushed from Workfront to AEM, that’s when the metadata is updated. Yep, and it’s only updated on the fields that are mapped. Got it.

So if I have this document attached and with that document, this document’s linked, indicated here by the chain link icon and there’s these fields. We are listening to that from a document level. So if I go back to my actual asset here, then we look at the asset properties. If I were to edit one of these fields, like say the asset description, but AEM can listen for those changes at the document level. I don’t think I mapped that field. But at the project level, that’s currently not a supported feature. So yes, AEM can listen for changes here at the document object level. But if I were to go, to answer your question more specifically, if I were to go back to that project details and I were to change this from yes to no and save it, AEM is not actually listening for this. The only way to get the new values is to then come and upload a new version.

I have a question. This is a new question regarding the user object. So first of all, thanks for explaining this metadata in detail. I’m wondering why are we creating custom fields or attaching metadata to the user field, user object and sending into AEM? How is the user object considered an asset? Yeah, as an actual use case would be, there are many, the type ahead field is used to ensure that, so like if we go back to this, that somebody is not putting an incorrect user’s name. So let’s say that there’s a sales lead that’s associated to this project. And we want the asset in AEM to know who that sales lead is, but the work front customer is using this type ahead field. So since it’s a type head field and it pulls in the user object, it’s not putting a string value, you know, titled Brian Fulton, it’s mapping it to a user object. And that user object has a bunch of values associated with it. So this is more of, we needed to develop a tool that could support this type ahead field, because the type ahead field isn’t just pushing a string array, it’s pushing an object that has a payload of lots of properties associated with it. So there are a lot of use cases that our work front customers utilize this type ahead field in their custom forms in order to add users to a custom form field.

But I’m still not clear why this information is stored in AEM instead of work front specific database or something. Yeah, so that’s a much broader question that you’re asking. And that’s really the value of the connector at its whole. So the goal here is that with the connector, so I’m gonna answer your question more generally speaking, there is lots of work front information. And that’s the point of the connector is to be able to take that work front information and store it alongside the asset in AEM. So the reason that becomes powerful is you’ve now just tied your work management system to work front to AEM using these values. So now if I’m an AEM user and I’m like, I need to find that asset that, I know it was from a campaign two months ago and Brian was the sales lead. Then I come in here and I can search for that name because we’re storing the metadata in AEM now. So now I can come search assets for Brian Fulton and that would be a metadata value that we stored. I could also say, okay, well, this is definitely a work front reference number for a project and I wanna be able to find that project. Well, then I can put that value in AEM and search by that value. So the value of the metadata mappings as a whole, not just this user object is that we wanna collect as much information from ideation. So when an asset hasn’t even been created yet, we know something about it, right? When somebody submits a request for a new digital asset campaign for their website. Well, we already know who the requester is. We already know what team it’s for. We already know what campaign it’s for prior to the asset being created. So we’re already starting to capture a ton of information and work front that then can become useful in AEM when we need to go search, discover, reuse, run reports. We have all that metadata now in AEM.

What we found is that everybody that uses the connector uses the metadata mapping feature. That’s not a feature that is like, oh, only some of our customers are using it. I would say that almost all of our customers use that. And even if they’re using it only to grab a work front reference number, right? So I wanna be able to store that reference number in work front alongside all of the assets that belong to this project, then it’s easy to find it. It’s like, well, rather than searching assets by name or trying to navigate through a complex folder structure to find the asset that I’m looking for, I can just go, well, I know it was a part of that one project to work for a couple of years ago. Let me just go search it. And then I type in the reference number and it’s part of the metadata. Could you just add a few words to that around? Cause I know calculated fields inside of work front custom forms are very typically used for a lot of these system generated fields in work front. Yeah. Just tack on to some of those. Totally. I think that’s a great point. So calculated fields is another one of those sort of special fields. So on top of the data type ahead, the object field and work front, you have this notion of calculated fields and work front. The calculated field is a fancy field that can do some sort of baseline calculations of reference fields. So let’s just walk through the most common example of that and then maybe highlight some of the other features. So again, when I’m building my custom form in work front, I can drag this calculated field. So this is a non editable field. It’s just a field that performs some calculation in the backend and then displays whatever the value of that calculation is.

Let’s go back to a actual project.

Let’s say for instance that we wanna map a field in AEM, but that field doesn’t appear in the dropdown. So if you see here, let’s do an example of one of those. Let’s say that I wanna pull in this like condition type field. You see this project condition, it says project status or progress status, or maybe yet let’s pull an even better one. Let’s do a projected completion date. So if I come over here and I try to search for projected completion date, you’ll see here there is no projected completion date as an option. But what if we really wanna be able to store that projection completion date in AEM? That way we have it as a searchable field or a field that we can run reports on. It’s probably more likely that it’s an actual completion date, but let’s just stick with this projected completion date. One of the ways that we’ve found a workaround to make those fields available is you utilize this calculated field. So I’ll come in here, I’ll add a calculated field. Let’s call this calculated field projected completion date. And then we can come down here and change this format to be date. And then we can come down here and actually point it to any of the fields. So I can just easily do this. And now I have this new projected completion date calculated field that I can save. And then if I come in here and refresh, I can then map that field. So I could come and drag a date value and call this one projected completion date. And then down here, if I go projected completion date, oops, did I label that right? Might not have labeled that right.

Oh, I said project, oops, I just spelled it wrong. Project completion date. Now I have that field that I can map to. So this is just one example, but really this comes into play anytime there’s an out of the box field. And those are most commonly found in this overview section. These are sort of the out of the box fields that are a part of any work front object. I mean, we’ll see these on tasks as well. If I go to a task on this overview section. So if there’s any fields here that you’d like to map to AEM, but you don’t see them as an option in this dropdown, well then all you need to do is create a calculated field, point to said calculated field, just like I did here, find it in this list below, add it, and then that field is available to map. So the reason for doing that is there’s just a lot of out of the box fields that we had to include. And it seems like, well, do we do the work to include every out of the box field? Or we just leverage out of the box tools rather than further customize the connector. So we opted to say, well, these tools are already available and at our disposal, let’s just use fields like calculated fields to solve those problems, rather than try to account for every out of the box field in the connector.