May 14, 2020

Think Like a Workfront Admin: Troubleshoot like a Pro!

Now that you have a Workfront Requests queue to track errors, it is time to show our admins how to troubleshoot Workfront using a real-life example (with historical Revolutionary War heroes as our users). 

Remember, in the first article titled, “Think Like a Workfront Admin: What is Troubleshooting?” we discussed four fundamental questions to ask after reviewing the technical support ticket: 

In addition, we identified the process for troubleshooting errors in Workfront: 

Let’s attempt to solve George Washington’s error in Workfront. 

George Washington submitted a request to the Workfront Requests queue as a Technical Support request. After reviewing the form, we have identified the error involves a report on a layout template: 

Based on the custom form, we can identify three out of four fundamental questions when reviewing Workfront errors: 

        1. George Washington is attempting to view a list of active projects he owns on the “My Active Projects” report in Workfront.
        2. George Washington has the Planner Access Level.
        3. George Washington’s Layout Template is Creative Director (based on the ID in the Custom Form).

 

The last question we need to answer is, “Does the user have the correct sharing permissions on the corresponding object?” In this case, we need to review the sharing rights on the “My Active Projects” report. 

Upon further investigation, we have identified that George Washington does have the correct sharing permissions for the “My Active Projects” report. The report is visible system-wide, without restrictions: 

 

Now it’s time to follow the troubleshooting process! 

      1. Answer the four fundamental questions for troubleshooting errors in Workfront.
      2. Log in as George Washington in Workfront. 
      3. Replicate the error by navigating to the Projects area and viewing the “My Active Projects” report. Picture 1 shows the results that George sees when reviewing the report and picture 2 shows the results George should see but does not:

 

 4. In order to properly resolve the error, we need to further investigate the key features of the report. 

          • First, review the report’s filters and determine that the filters are set up correctly (we use wildcards to make the report dynamic).

          • Next, review the report’s settings and notice that we accidentally set the “Run this report with the Access Rights of Andy Koprowski.” When selecting a user in the “Run this report with the Access Rights of” field, it will overwrite the existing filters of the report. So, instead of viewing active projects with an owner ID equal to $$USER.ID, the report will instead show all active reports owned by Andy Koprowski. 

          • To resolve the error, remove Andy Koprowski from the field, “Run this report with the Access Rights of” and save changes to the report.
          • Next, log back in as George Washington and confirm that the update to the report resolves the error: George can now view all of his active projects.

          • Remember to respond to the error ticket, informing the user that the error has been resolved and move the status of the ticket to Closed. 

 

In our next blog in the “Think Like a Workfront Admin” series, we will discuss how to create advanced reports using advanced views.

Go back to Blog