Expand my Community achievements bar.

Join us LIVE in San Francisco on November 14th for Experience Makers The Skill Exchange. Don't miss out on this free learning event!
SOLVED

My People’s Work Universal Dashboard | Calculated Field

Avatar

Level 3

Hi @skyehansen - I came across your People's Work Universal Dashboard and am interested in re-creating the reports and dashboard for a group that I managed. I've read the instructions a couple of times and when I configured it, I keep getting an error where the field "Manager" is not recognized. I tried to troubleshoot it myself and even went online and found a posting from previous users who are also experiencing the same issue. I don't believe "Manager" is a native field in Workfront. If its a custom field does that mean there should be two fields created? One text field and one calculated field? Can you provide some further guidance on how to resolve the issue? 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

hi there Annie, thank you for letting me know. I think probably @jon_chen  is the best person to assist in coordinating any changes or updates needed to this and the other post you're referring to.

 

Jon:

 

1) most critical: the reporting cookbook was published in 2021, and in 3rd quarter 2022, Workfront released a feature that impacted all information about calculated fields that was published in the Community before 3rd Q 2022. The feature changed all the field names from "Friendly Names" to "camelCase". This includes the calculated field expression published in the reporting cookbook. Do you happen to know who would have the controls over the current cookbook to get this expression updated? 

 

2) fairly minor: feels like the instructions could use a rewrite to make things a bit easier to understand. Annie, maybe you and Jon could work together to write this out in a way for newer users to understand?

 

Annie: to answer your question: "Manager" is not a "native field", it's an object (e.g. "project", "task", and "issue" are not native fields, they are objects). The way you can tell this, is to go to the api explorer, and pull up the user object to look. On the user object, you should see a field called "managerID" (indicating a higher level object with an ID), and this is usually a hint for you to look in the "reference" tab of that object. When you click on the reference tab of the user object, you should see a reference for "Manager". 

As a new reporter, you already have done very simple referencial calls, like "project.name" for example -- referencing the Project object to get its name. So looking at the calculation from that respect, you can see where we're referencing the "Manager" object to get its name in the same way. In fact, our referencing goes 4 or 5 levels deep!

Really, the only thing you need is the updated syntax for 2024 use. I think a general rule of thumb is to replace all the Sentence case words with camelCase e.g. "manager" instead of "Manager", managerID instead of "Manager ID"). Also surrounding each reference or fieldname with curly braces. (e.g. {manager}.{manager}... and so on)

 

Let us know how it goes.

View solution in original post

7 Replies

Avatar

Correct answer by
Community Advisor

hi there Annie, thank you for letting me know. I think probably @jon_chen  is the best person to assist in coordinating any changes or updates needed to this and the other post you're referring to.

 

Jon:

 

1) most critical: the reporting cookbook was published in 2021, and in 3rd quarter 2022, Workfront released a feature that impacted all information about calculated fields that was published in the Community before 3rd Q 2022. The feature changed all the field names from "Friendly Names" to "camelCase". This includes the calculated field expression published in the reporting cookbook. Do you happen to know who would have the controls over the current cookbook to get this expression updated? 

 

2) fairly minor: feels like the instructions could use a rewrite to make things a bit easier to understand. Annie, maybe you and Jon could work together to write this out in a way for newer users to understand?

 

Annie: to answer your question: "Manager" is not a "native field", it's an object (e.g. "project", "task", and "issue" are not native fields, they are objects). The way you can tell this, is to go to the api explorer, and pull up the user object to look. On the user object, you should see a field called "managerID" (indicating a higher level object with an ID), and this is usually a hint for you to look in the "reference" tab of that object. When you click on the reference tab of the user object, you should see a reference for "Manager". 

As a new reporter, you already have done very simple referencial calls, like "project.name" for example -- referencing the Project object to get its name. So looking at the calculation from that respect, you can see where we're referencing the "Manager" object to get its name in the same way. In fact, our referencing goes 4 or 5 levels deep!

Really, the only thing you need is the updated syntax for 2024 use. I think a general rule of thumb is to replace all the Sentence case words with camelCase e.g. "manager" instead of "Manager", managerID instead of "Manager ID"). Also surrounding each reference or fieldname with curly braces. (e.g. {manager}.{manager}... and so on)

 

Let us know how it goes.

Avatar

Level 3

That makes sense why there would be an error if field names have been updated to camelCase. I just assume "Manager" was a field name to User object because the instruction is for creating a calculated field. I will try updating the syntax and let you know. 

Avatar

Community Advisor

My analogy would be that if you are creating a calculated field on a task, you are not restricted to task fields names. You could go with {project}.{name}, which is a field on the project object, or {project}.{portfolio}.{name}, which is a field on the portfolio object, that you need to go to the project object for.

So with that in mind, think about the way you would put the user's manager into the calculated field, vs. the user's manager's manager, and so on.

Avatar

Level 3

Thanks @skyehansen. I did manage to get the calculated field to work by updating the syntax and adding lots of {}...I'm just glad I got it to work and now I can play around with it some more.

 

Reports:

  • I wasn't able to get the 4 assignment reports to work but I realized many of the projects do not have tasks assigned to users yet. I assume this the reason for the blank reports.
  • Project reports are working, but for some reason I have one user who cannot see its direct report's reports. 

Avatar

Community Advisor

great, glad you got that all working. the assignment reports are all keyed to the user who is viewing them, so if you don't get assigned to anything and if you're not a manager of users who are assigned to anything... then you would see blank reports.

 

For the other bullet point, you can always put in a case with Support to do some troubleshooting -- I've heard they like that kind of thing from time to time.

Avatar

Level 4

Hi Annie! Can you please share the calculation you used to get this to work in the calculated field? THANK YOU!

Avatar

Administrator

Hey @skyehansen Thanks for the callout. In addition to the caluclated fields change, it's possible that many of the recipes in the 2021 cookbook are obsolete due to product releases in the past 3 years. Let me do a deeper dive into each individual recipe and see if it makes sense to publish an updated version or archive the 2021 version.