admin Tag

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.

In our new series, “Think Like a Workfront Admin,” our consultants will walk you through how to troubleshoot Workfront like a pro!

Are you a new Workfront system administrator? Or perhaps you are a seasoned Workfront administrator looking for new ways to troubleshoot system errors. Either way, you’ve come to the right place.

First, we need to start with the basics and answer the following questions:

‘What is troubleshooting and how do you troubleshoot Workfront errors?’

Any software application, no matter how advanced, will need to be troubleshot by a system administrator or software subject matter expert from time to time. I’ve been in the IT world long enough to know that even the simplest line of code can break and when it does, it is best to be prepared with the right questions to quickly fix the problem.

So, what is troubleshooting?

Troubleshooting is identifying a problem, understanding the root cause, and correcting the problem. That’s it!

Next, we will discuss, how do you troubleshoot errors in Workfront?

Typically, errors are identified by your users. That’s right, the standard plan, work, and review license users will find more errors than you, the system administrator. Let’s be realistic, every system administrator builds Workfront to work, but Workfront doesn’t always work as expected. Don’t take it personally (I had to learn that the hard way). Just remember, it’s your job to identify the root cause and quickly solve the problem.

When an error is identified, you should ask the following questions:

When you answer all of the questions above, you will typically find the root cause of basic problems in Workfront. I cannot tell you how many times users have reported “errors” that weren’t actually software errors, rather, the user needed an upgraded license, access level, and/or layout template.

To make things easier, I execute the following process for each error:

 

After following the process above, if you aren’t able to identify the root cause and resolve the error, you will need to submit a ticket to Workfront Support for additional help.

In the next post, we will discuss “How to create an internal request queue to track and resolve errors that your users identify.”

Stay tuned.