Custom attribute same name, different calculation?

[EricLu2]

Hi - I'm curious to know if this is a valid statement: I want a custom calculated attribute on, say, the task object. I want to show that custom attribute on multiple forms. On each form, however, I want the calculation for that attribute to be different. I want the name to be the same, but I want the calculation to be different per form. I have a calculated attribute that I want to display on multiple forms. When I copy the attribute from the Field Library to a new form, it does not bring over the calculation. I was just told that WorkFront is working as designed. I can't figure out when anyone would want a calculated attribute with the same name, but a different calculation on different forms. Here is what I was told: "This is working as designed. Calculated field formulas can vary from form to form that's why if you add the field from Field Library, the calculation will be blank. For example you can use the same calc field on a project and task forms, in which case the fields will not be the same so the calculations will also need to be different." Does this sound right to anyone? If so, let me know why you need the same calculated attribute to have a different calculation on different forms. Thanks! Eric

[Doug_Den_Hoed__AtAppStore]

Hi Eric, Yes, that sounds right, and is an As Designed technique that all of my "http://www.espsuite.ca">ESP for Oil & Gas clients rely on. ESP uses Workfront as its underlying platform to track complex Oil & Gas projects from exploration through to on production. There are dozens of types of capital intensive projects (e.g. Gas Wells, Oil Wells, Facilities, Pipelines, etc.). Each project uses a (staggeringly) large amount of custom data behind it to model the industry specific information. A good portion of that data relates to capital costs. Those capital costs vary by project type. Each, though, has a calculated custom parameter called Total Capital Cost...but the formula varies depending on the project type. For example, on an Oil Well project, Total Capital Cost would be the sum of the Construction, Drill, Completion, Pipeline, and Tie In custom data parameters (each of which is also entered at the project level); but on a Pipeline project, the Total Capital Cost would simply be the sum of the Construction and Pipeline, since Drill, Completion, and Tie In do not apply (nor are they even present) on a Pipeline project. In doing so, we can report the Total Capital Cost across multiple projects in all the usual ways within Workfront, conceptually simplifying to treat them as the same thing (e.g. when monitoring against our capital budget), but in fact allowing each to be driven by its natural underlying components, which is also important (and reported separately). Regards, Doug

[SkyeHa]

I just used it last week in order to do something new---bring a bunch of values into the same column on a report and I really liked the result. I had 3 different types of requests for 3 different sets of events (for example, the conferences request had 3 different types of conferences, the product team had 3 different types of launches and the management events had 3 different types of events). However, the three teams are from the same division and they wanted to see all of these events in the same report and have them group by the type of event. So if I made a calculated field called "event calc" and just used it to repeat exactly what was chosen in each request (two were radio button fields and one was a queue topic ID), then I got a column with all 9 event types. I felt it was a more elegant solution than sharecol-ing a bunch of columns together.

[Doug_Den_Hoed__AtAppStore]

Epilogue: in your case, if your preference is that each calculated field have the same formula across all custom forms, I can think of two other options: paste the formula into the description of the calculated custom parameter, so it will always be "handy" to copy and paste as you add that field to new custom forms (crude, but effective...until the formula changes) consider breaking that calcuated field out onto its own custom form so that the formula lives only in one single place, and instead, add that "entire" custom form to whatever other forms you need (clever, if the formula is likely to change...except for the why-isn't-it-recalc'ing-when-I-expect-it-should uncertainty) Regards, Doug

[MartyGa]

Nice post, as always, Doug. At first I was stumped as to WHY a custom data element needed to be re-created for each form it was on. You and Skye explained it well. With the advent of multiple custom forms being allowed on an object, we've been using some standard forms for the things that ALL work must have attached, then break out the unique elements specific to a unit in a separate form.

[EricLu2]

Okay, I will concede that some are getting value from reusing a custom attribute name without reusing the calculation. If the calculation results in the same business semantic, and if the form the attribute appears on uniquely differentiates the calculation needed, I can see how that might work. It is so very easy, however, to reuse the name and have a calculation that results in a different business semantic. Scratching my head with begrudging acceptance…… Eric