51ºÚÁϲ»´òìÈ

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 51ºÚÁϲ»´òìÈ 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 51ºÚÁϲ»´òìÈ 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 51ºÚÁϲ»´òìÈ radio button, and then give this unique name.

And then I can map it to that 51ºÚÁϲ»´òìÈ 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, 51ºÚÁϲ»´òìÈ Date, if I come down here and try to do my mapping, we’re not going to see 51ºÚÁϲ»´òìÈ 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 51ºÚÁϲ»´òìÈ 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 51ºÚÁϲ»´òìÈ 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 51ºÚÁϲ»´òìÈ 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 51ºÚÁϲ»´òìÈ 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 51ºÚÁϲ»´òìÈ demo. And let’s say I add that custom form.

So 51ºÚÁϲ»´òìÈ 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