What is {portfolio|portfolioMM}.{name}

[tibormolnar]

Hi All,

recently I found a calculated field in our instance created by someone earlier, that includes this reference:

{portfolio|portfolioMM}.{name}

Could someone please explain me what this is / how it is different from {portfolio}.{name}

I searched the forum and this came up a few times, along with {programMM|program}.{name}, but w/o any explanation about the MM part.

Thank you,

Tibor

[skyehansen]

portfolioMM doesn't work, so you can just remove it. If I recall correctly, the pipe symbol just means "or"? So in this case your calculated field is looking for portfolio or portfolioMM name, and so it doesn't error out because one of those is true. But go ahead and create a calculated field for just {portfolioMM}.{name} and you will see when you try to save the custom form, you will get an error that the field does not exist. Conversely if you were to go with {portfolio|hamburger}.{name}, this would also work despite the fact you don't have a hamburger field in Workfront.

I'll let you test the program one out, yourself. A good way to test it would be to make a program report and pull up those two columns, and then add the custom fields to the program and see if you come up with any data in those fields. (I suspect you'll find that you instead get the same error message.)

I was wondering to myself if maybe the portfolio field used to be called portfolioMM and this kind of calculation was put into place as a transition step. But I went back to API v4.0 and as far as I can see, it has always been portfolio.

[tibormolnar]

Thanks for the quick response!

I had thoughts similar to yours. Still, it doesn't seem to make much sense.

I did some testing and found that all these work:

• {foo|portfolio}.{name}
• {portfolio|foo}.{name}
• {foo4|foo1|portfolio|foo2|foo3}.{name}
• {foo4|foo1|enteredBy|foo2|foo3}.{name}

So I was wondering what happens if I use multiple existing references and tested these:

• {portfolio|enteredBy}.{name}
• {enteredBy|portfolio}.{name}
• {enteredBy|portfolio|group}.{name}

Again, all these work. Apparently, the first existing reference in the list is used, the rest is ignored.

Two questions remained open though:

What's the use case that this logic was meant to serve?

What is/was the reference portfolioMM?

[KellieGardner]

After reading your question I was intrigued. I've never used the fields that end in MM and I've even seen ones that end in OM. 

Someone on my team was able to get an explanation from someone at Adobe on the MM and OM:

"Typically it means that the data you'll get back is an amalgamation/combination of a group of data. To get that data it requires Workfront to run some additional logic to compile the data and transform it for use in the API, but what you get back the "OM" or "MM" field isn't a representation of an actual data object/data set you can interact with directly if that makes sense."

(Amalgamation is a process of combining or uniting multiple entities into one or merging two or more source files into a single file)

[RandyRoberts]

In some other languages, MM means "many to many" and OM means "one to many".

[tibormolnar]

I  understand Adobe's explanation for MM/OM, in general, however it's difficult to apply to a referenced object's name (i.e. the Portfolio of the Project).

Anyway, I think I will just simply remove the "programMM|" part from the calculation.

Thank you all for the inputs!

[Doug_Den_Hoed__AtAppStore]

Hi @tibormolnar,

Like @skyehansen, I too was intrigued by your question...but now I am vexed,

Yesterday, I was working with a SysAdmin to help her doublecheck the setup for their 6th year of using our Budget vs Actual solution, which her organization uses to set Portfolio, Program, and/or Project level budgets for the upcoming year, then monitor Budget vs Actual dollars and % throughout the year.

We traced through every step together carefully, and were puzzled to confirm that everything appeared to be in order...until, on a hunch, we examined the custom calculations.

Having developed and entered them myself when we designed this solution over 6 years ago, I can assure you that neither I nor any end user entered the  "{portfolio|portfolioMM)" in the formula we checked...let alone the dozens of others in similar related calculated parameters. Furthermore, I found it suspicious that the editor considered all of them valid (ie did not show a red outline; unlike, say "If", vs the snobbier "IF"), despite none of them being shown as an option to select from the typeahead formula field picker.

My current theory is that:

• this is an unfortunate side effect of a recent change to Workfront that for some reason included the systematic replacement of {portfolio} with {portfolio|portfolioMM}, among others, and
• that the | character (perhaps treated similarly to a regex or behind the scenes) is defeating - whether As Designed or by fluke - the editors "invalid formula" red border logic, and
• that  the root cause (or branch cause, for those who enjoy source code control puns; and who doesn't?) is: the recently released feature to onscreen dynamic calculation (ie as you type, before you save) logic

So: with my SysAdmin access reinstated for the occasion, coffee perking, and dander up, I am about to get to the bottom of this.

Stay tuned.

Regards,

Doug

PS. @LilitM...since the New Editor was one of your outstanding achievements, want to Come With...?

[tibormolnar]

Hi Doug,

thanks for the feedback and good luck with the investigation / clean-up.

I'm looking forward to hearing from you.

Tibor

[Doug_Den_Hoed__AtAppStore]

Hi @tibormolnar,

Well, I will defer to @LilitM to explain the root cause, but after some bumpy API off roading and Form Builder experimentation, believe I’ve worked around it for now:

What eventually worked was to:

• CUT the affected formulas out
• CHECK the Apply to existing calculations box (with the calculation box blank) and SAVE
• Wait a few seconds for processing (and good luck)
• PASTE the affected formula back in
• EDIT the formula to remove the offending |portfolioMM portion (as we've been discussing with @skyehansen et al)
• CONFIRM that the formula editor agreed that the resulting {portfolio}.{name} is indeed valid (i.e. no red)
• CHECK the Apply to existing calculations box (with the calculation box blank) and SAVE
• Wait a few seconds for processing (and good luck)
• CONFIRM the results (both visually, and via the API)

Although I worked out a way to pull back both Parameter Values and the underlying Custom Expressions in a single API query for easy examination, I suspect that there are many other formulas (across many domains, in my case) that need the above workaround to ensure the calculated data is up to date and correct.

If this is as widespread as I suspect it might be, I am considering building a detect-and-fix-the-formulas option in our Recalc Helper solution.

But for now, at least there is this workaround.

Regards,

Doug

[tibormolnar]

Hi Doug,

so, is the following a fair summary of the findings?

• We don't know how the "|PortfolioMM" portion got into the formulas in the first place. It may be a side effect of something that Adobe did.
• Seemingly it doesn't change the behaviour of the formulas and can just as well be removed.
• Removal is slightly tricky: First the formula needs to be completely removed (and applied), then re-added without the "|PortfolioMM" portion (and applied). Otherwise the calculated values may not get updated properly.

Thank you for the investigation.

Tibor

[Doug_Den_Hoed__AtAppStore]

Hi Tibor,

Yes, although further confirmation, your summary matches my speculation so far, noting that I am also wondering:

• whether the "|PortfolioMM" was intentional
• if so, the purpose of the "|PortfolioMM" (e.g. the real-time onscreen recalcs)
• whether a "|PortfolioMM" will come back (behind the scenes) if it is removed manually
• what advantage (if any) that brings
• whether there are other similar "|" suffixes that have been injected into Calculated Expressions
• whether those creating Calculated Expressions should be learning why and how to include such "|" suffixes
• if so, whether the Formula Builder will be enhanced to help do so (i.e. currently, typing "portfolio|" yields no results in the Formula Builder typeahead)
• how to (ideally, easily) find all occurrences of such "|" calculated expressions so they can be adjusted manually if need be (ouch)
• whether the steps I outlined (i.e. remove, apply, replace, apply) to ensure the calculated values stored in the database (vs onscreen) are As Designed or a bug, and if a bug, when it will be fixed

Given that many of our 50+ solutions across many of our clients rely on custom expressions, those last two concern me the most, so I am doing a bit more research.

In particular -- especially if formulas are going to be changing unexpectedly going forward (even if For Good Reason) -- I'm going to run some tests to assess whether our Recalc Helper solution (without having to continually hunt and peck for such changes) would ensure to our clients that all calculated expressions are up to date and accurate.

Regards,

Doug

cc: @SamTaylor as per sidebar...

[Doug_Den_Hoed__AtAppStore]

Hi @tibormolnar,

I've now completed my research:

• I have tracked down the root cause of the behavior I was observing
• I can reproduce the behavior
• I am observing a "loophole" in calculated parameter recalculations: a calculated parameter on one object type that refers to another -- i.e. on a program to a portfolio name, in my case -- does not recalculate automatically and instantly, nor even in a timely fashion (+3 hrs and counting in my research today...which I now think I remember being something I knew but had forgotten)
• I confirmed that our Recalc Helper solution does close the loophole without the "remove, apply, replace, apply" manual workaround I described above, even for formulas that include the mystery (still, at this time) "|portfolioMM" suffix, meaning that I do not have to worry about (or worse, hunt and peck) for them
• I noticed a parallel to this cross project predecessor timeline loophole, which Recalc Helper also solves
• I documented my research in the screenshot below

So! (Re)equipped with this understanding, I am going to share this information with our existing clients so they are aware of it, and for you and others who may come across this and suspect it might impact your organization, suggest you:

• periodically manually recalculate (i.e. remove, apply, replace, apply) such custom data
• write a Fusion Job to do so for you, if you have the means
• contact me via doug.denhoed@atappstore.com if you think our Recalc Helper solution might be a good fit

Regards,

Doug

cc: @SamTaylor 

[Doug_Den_Hoed__AtAppStore]

Hi @tibormolnar (and those following),

As below, I am pleased to invite you to try out our Recalc Helper solution for 30 Days so users can easily ensure all of their Custom Data (and Timelines, and Expenses) are up to date.

Regards,

Doug

CC: @SamTaylor