My People’s Work Universal Dashboard | Calculated Field | Community
Skip to main content
A
AnnieXLe
Level 3
April 8, 2024
Solved

My People’s Work Universal Dashboard | Calculated Field

  • April 8, 2024
  • 1 reply
  • 1803 views

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? 

Best answer by skyehansen

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.

1 reply

skyehansen
Community Advisor
skyehansenCommunity AdvisorAccepted solution
April 8, 2024

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.

    A
    AnnieXLeAuthor
    Level 3
    April 9, 2024

    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. 

    skyehansen
    Community Advisor
    skyehansenCommunity Advisor
    April 9, 2024

    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.

    Terms & ConditionsAccessibility statement

    Loading footer...