Project Form Calculated Field to Pull in Portfolio Manager Name

​@Laramie_Newborn  I know there is a way to do this. Trying checking out this link I found in the Workfront documentation. You might have to adjust the text mode provided since your talking about a Portfolio object instead of an Issue. 

https://experienceleague.adobe.com/en/docs/workfront/using/reporting/reports/calculated-custom-data/custom-field-manager-issue-creator-on-issue-form

Also, make sure your familiar text mode and some advanced logic. I’m always trying to brush up on this stuff. 

https://experienceleague.adobe.com/en/docs/workfront/using/administration-and-setup/customize/custom-forms/design-a-form/advanced-logic-examples

To clarify, are you looking to pull in the native WF portfolio owner field?  I think you can use this on your project form calculated field:

{portfolio}.{owner}.{name}

Kristen's syntax is right — {portfolio}.{owner}.{name} will pull it onto the project form. Before you build it, though: for what you're actually trying to do here, group a report to make a chart, I'd skip the field entirely.

Why: cross-object calculated fields store a snapshot. The value computes when the project is saved, and when the field it points at changes on the parent, the child does not recalculate. Reassign a portfolio to a new manager and every existing project keeps the old name until something touches it — an edit and save, "Recalculate Custom Expressions" from the object's More menu, or a bulk edit through a report. So the chart keeps rendering last quarter's manager and looks perfectly healthy while doing it. It's the most common source of quietly wrong data I run into in Workfront reporting.

What I'd do instead is group on the join directly, in text mode on the report's grouping tab:

group.0.valuefield=portfolio:owner:name

group.0.valueformat=HTML

group.0.linkedname=direct

No stored field, nothing to recalculate, and it reads current data at render time. One thing to know: groupings can only reach two objects deep, and portfolio to owner is exactly two, so this works but sits right at the ceiling. Anything a hop further out does need a calculated field on the closer object — that's the case where the field genuinely is the answer.

Two smaller notes if you build the field anyway (there are fair reasons — exports and some downstream consumers can't traverse the join):

Decide the Format before the first save. Once a form containing a calculated field is saved the first time, the Format is locked, and the only fix is deleting and recreating the field.

Make the recalculation step part of the documented process, not something someone remembers. If nobody owns it, the field is wrong within a month.

The text-mode and calculated-field notes I keep open-sourced cover the grouping depth cap and the recalc traps in more detail: github.com/Thousand-Cuts/wf-toolkit