What is {portfolio|portfolioMM}.{name} | Community
Skip to main content
tibormolnar
tibormolnar
Level 4
January 23, 2025
Question

What is {portfolio|portfolioMM}.{name}

  • January 23, 2025
  • 4 replies
  • 1542 views

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

4 replies

skyehansen
Community Advisor
skyehansenCommunity Advisor
January 23, 2025

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
    tibormolnarAuthor
    Level 4
    January 24, 2025

    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
      Community Advisor
      KellieGardnerCommunity Advisor
      Community Advisor
      January 24, 2025

      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
        Community Advisor
        RandyRobertsCommunity Advisor
        Community Advisor
        January 25, 2025

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

          Doug_Den_Hoed__AtAppStore
          Community Advisor
          Doug_Den_Hoed__AtAppStoreCommunity Advisor
          Community Advisor
          January 30, 2025

           

          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
            tibormolnarAuthor
            Level 4
            January 30, 2025

            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
              Community Advisor
              Doug_Den_Hoed__AtAppStoreCommunity Advisor
              Community Advisor
              January 31, 2025

              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


               

              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...

                kautuk_sahni
                Community Manager
                kautuk_sahniCommunity Manager
                Community Manager
                September 1, 2025

                @tibormolnar Hi there, just checking in. Were you able to get this resolved? If one of the replies above helped, even if it didn’t fully solve the issue but pointed you in the right direction, marking it as accepted can still guide others who may face a similar question. And if you discovered another way to fix it, sharing your approach would be a big help to the community. Your follow-up not only closes the loop but also ensures others benefit from your experience. Thanks again for being part of the conversation!

                Kautuk Sahni
                Terms & ConditionsAccessibility statement

                Loading footer...