Think Like a Workfront Admin: Create Reports like a Pro with Workfront’s API Explorer!

Think Like a Workfront Admin: Create Reports like a Pro with Workfront’s API Explorer!

            Now that you are troubleshooting Workfront like a pro, it is time to sharpen your reporting skills. How many times have users asked to create advanced reports that show the number of hours remaining on a task and project or the number of days a task was late? When I was a Workfront System Administrator, my users constantly requested reports that automatically generated the KPIs above. But before we begin creating advanced reports, let’s learn about Workfront’s database structure and how to use the Workfront API Explorer.        

Every Workfront System Administrator should become familiar with the API Explorer. The API Explorer will teach you how different objects are linked together, the reporting limitations within each object in Workfront, and it will eventually prepare you to create amazing reports and integrations!

         First, you can find Workfront’s API by visiting Workfront’s Help site and searching for API Explorer (or by clicking here). The API Explorer is a large table that allows System Administrators to expand each object to see the different fields and components of the object. The API Explorer is broken down into the following parts: The Filter box, Object List, and API Version dropdown.

 

 

The API Version dropdown allows System Administrators to select different versions of Workfront’s API. I recommend selecting the most recent API version for a complete list of fields, references, collections, and actions per object. You don’t need to focus on reviewing different versions because Workfront’s production site will always leverage the most recent API version, which is what you need for advanced reporting.

The Filter (or search bar), allows you to quickly find the object you want to review. If you type “Project” in the Filter bar, the API Explorer will show a list of objects with Project in the name. The Filter bar is a great way to quickly find the object you want to review.

Lastly, there are objects within the table. Each object can be expanded for further detail. Each object has five subtabs: Fields, References, Collections, Search, and Actions.

1) The Fields subtab:

    • The Fields subtab is a comprehensive list of native object fields that can be used on an object report. The API Explorer only shows native Workfront fields, though you can leverage object custom fields in an object report. For example, if I select the Project object and choose the fields subtab, I will see a list of Project fields (like name, description, etc.).
    • Different fields have different field attributes. Each field is expandable for additional detail. Each field will have at least the Field Name and Field Type, but some fields have a lot more information.
    • Each field displays the label (what you see in Workfront) and the camel case name. The camel case name of each field is important when writing custom text mode within a report (I will show you how to use camel case field names in the next blog). Camel case refers to the style in which the fields are written, which is capitalizing the second word within the name. For example, the Planned Start Date field on a Project is actually called plannedStartDate. As you can see, Start and Date are both capitalized and form “humps” within the string.

 

2) The References subtab:

    • The References subtab is a list of all referenced objects that connect to the object you are reviewing.
    • Similar to the Fields subtab, each referenced object can be expanded to see additional detail.
    • The referenced objects are either one level above or parallel to the object you are reviewing. Think of objects as a pyramid. There are different levels within a pyramid and each level “connects”, either directly or indirectly to another level. For example, a referenced Project object is a Portfolio. A Project can only be associated to one Portfolio.
    • Each referenced object has a hyperlink that you can select, which will navigate you to the object within the API Explorer.

 

3) The Collections subtab:

    • The Collections subtab is a list of connecting objects that are grouped within the object you are viewing.
    • To maintain our Pyramid analogy, a collection object on a Project is the Task object. You can have many different Tasks on a single Project, but Tasks are a lower level on the Object Hierarchy. Think of the Object Hierarchy this way: Portfolio (top-level) à Program à Project à
    • You are limited on how you can leverage collection objects within a report, but we will cover that in a future blog post soon!
    • Each collection object has a hyperlink that you can select, which will navigate you to the object within the API Explorer.

 

4) The Search subtab:

    • The Search subtab is used primarily in Custom API calls. Custom API calls are traditionally used by iPaaS (Integration Platform as a Service, like Fusion) solutions or custom application software.

 

5) The Actions subtab:

    • The Actions subtab is used primarily in Custom API calls. Custom API calls are traditionally used by iPaaS (Integration Platform as a Service, like Fusion) solutions or custom application software.

 

Now that you understand the Workfront API Explorer and its different components, you are ready to create advanced reports within Workfront. In the next blog, we will review how to use the API explorer to create Advanced Views.

 

Andrew Koprowski
akoprowski@leappoint.com

I am a certified Workfront Partner (and systems administrator at heart) that works with IT PMOs and Marketing teams to successfully configure and implement Workfront. My goal for every implementation is to drive meaningful and lasting change. I believe that in order to successfully implement Workfront, organizations need more than enthusiasm and executive support. Organizations need to configure and structure Workfront for short-term success and long-term expansion.

No Comments

Post A Comment