Workfront app walkthrough

Transcript

The Workfront app, like any other app connector, contains modules organized into three sections, triggers, actions, and searches. In three upcoming videos in this course, we’ll dive into each section, highlighting the different modules available, and how each one can be utilized. Being familiar with Workfront’s API and event subscription capabilities will give you a better understanding of how modules are structured and what’s possible in fusion. Remember that the limit on the standard modules available for any app, not just the Workfront app, will be determined by what the platform API allows. As we continue to develop the Workfront app, you’ll find more default modules available within the list. If there isn’t a module available that you need to use, and you know that the API is capable of performing the action, you can always use the custom API call module. But more to come on that in the video on actions. As you go through the next videos, you may want to create a new scenario to follow along, and possibly have your Workfront test drive pulled up to run any tests.

The Workfront app provides three types of triggers to kick off your scenario, watch events, watch field, and watch record. All three of these triggers are tied to the capabilities of the Workfront Event Subscription API. You can use the link below this video if you want to read more. If I choose the first trigger type, watch events, I actually have to establish a webhook for information to travel to. To do that, I’ll click the add button at the right hand side, and give my web hook a name. In this case, I’ll listen for new projects created. Below my connection, I’ll choose projects as the record type, and for filter, you can see that you can listen for new records only, updated records only, new and updated records, or deleted records. In this case, we’ll choose new records only, and save. You can see from the message that we’ve attached this webhook to the Workfront automatically for you. At this point, you can click OK, and then continue building your scenario using filters to exclude certain types of projects created, or whatever you need. Let’s go ahead and delete this module and check out the second trigger type. For watch field, you can actually find a certain type of record in a field on that record to monitor when that field changes. In this case, I could say that I want to monitor issues, and the field that I want to monitor on issues is the status, which I can find by typing in once I click into the dropdown menu. You can set a limit so that each execution is not pulling in every single issue within the system, but per cycle will pull in 20 records or 20 potential issues with a change status field. Once I click OK, then I can, of course, choose where to start for the records in the system, and I’ll simply say “All” for this quick video. And then, of course, I’d continue building my scenario and apply filters after this module to go for only specific issues. Let’s check out the last trigger module. For watch record, I have a few more options. For filter, it’s similar to our watch events trigger where I can determine that I want to look at new records, updated, or new and updated records. For record type I, of course, have a similar list of objects within Workfront. In this case, let’s try picking note. Once the outputs generate, I can decide that when new updates or new notes are created within Workfront, what information do I want to gather about that update, potentially the ID, or the text. In the optional filter field, I do need to know some basic text mode coding. In this case, if I type in objCode for object code =PROJ, in all caps, I only want to look at new updates or notes left on projects.

Again, I have a limit that I can set for the number of notes that I process per execution, but I’ll leave that at 20 and click OK.

When looking at the list of available actions in the Workfront app, remember the CRUD operation principle, create, read, update, and delete. In the selection of modules available, we can see the create record, read a record, update record, and delete record modules. There’s also download and upload a document, miscellaneous actions, and custom API calls. The use of the CRUD operation modules is fairly self-explanatory, but it’s important to note that actions only process one bundle or record at a time, and all actions require a specific ID to process. For the create record modules specifically, you’ll want to become familiar with the required fields to avoid errors. When creating a task, for instance, the task name is required to create a task. If you forget that step or leave that field empty, you’ll probably result in an error. So let’s first spend time looking into the miscellaneous action module. When I click into this module, I first have to select the record type. In this case, I’ll simply select issue. Issues will have a unique set of actions based off of how our API has been configured. In this case, an issue might be converted to a project, marked as complete or unassigned. When you select a certain type of action, say convert to a project, a list of fields may appear that you need to fill out to convert and create that project. If I choose a different record type, say user, the list of a available actions will change. We recommend going through each record type and becoming more familiar with the available actions that you can use. The other option is you can go into the API explorer and filter down to a certain object table, and the far right tab will show you the available actions that you can use. Now let’s go back into our Fusion system and check out the custom API call module. What’s great about this module is you’ve already established a connection and authenticated yourself through the Fusion system. So when writing out your URL calls or requests to the Workfront system, you can simply write out the action you want to perform. In this case, I’ll type out project/search?status=CUR, or current.

Meaning, I want to go into my test drive and search for any project that has a status of current, and return information about those projects. If I click okay and run once, I’ll see that I have one successful execution for my custom API call, and if I open the execution inspector and go into the body and the data, I can see that there are 40 projects within my Workfront test drive that are in a status of current. To be proficient at using the custom API call module and to use it to its max capacity, you’ll need to become very familiar with the API calls that you can make to the Workfront system. To learn more, there is a support article linked below this video, called API Basics.

The Workfront app offers two search modules, a generic search for different types of records or read related records within specific object types.

The search module can be used as a trigger on your scenario to go into Workfront and pull information out and run it through your scenario. The read related records, however, kind of acts like an action module in that it needs a specific ID to go into a record and pull information out for the collection. Remember that searches behave like iterators, they will return zero, one, or potentially multiple bundles of information to pass through your scenario. Let’s take a closer look at the search module first.

The first thing that the search module needs to know is what record types within Workfront do you want to search for. In this case, I’m going to choose tasks.

Then I need to decide for the total maximal number of tasks that I can find within each given execution, do I want to pull in all matching records or the first matching record that the search module finds? Below that, I can establish search criteria, so I might be able to pull in 200 tasks but do I want to pull in any random 200 tasks or filter down to a specific type or set? Finally, I need to decide what types of outputs do I want to pull from the tasks that I find within my Workfront system. In this case, I’ll just simply select ID for now. Go ahead and click OK and run once, if following along.

You’ll notice that you have one successful execution performed on that trigger module. If you click into the execution inspector, you can see that you probably have around 200 tasks that have been pulled in, because we only set the limit at 200 and no criteria or filters to determine what tasks you want to pull specifically. To understand how the read related records module works, I’ll click out of this panel and go into add another module and choose read related records.

For the record type that I choose from, this is the record that I want to dig into and pull information out of. In this case, I’ll choose the tasks that we searched for in our search trigger. I’ll specify that for whatever tasks the search trigger finds, we’ll go ahead and grab that ID, and then each time a task or record passes through this read related records, we want to take a look at the documents attached to each task. Again, we can determine what types of outputs related to the documents we want to pass further down through our scenarios, such as the ID or maybe the name. -