Tunnel Of Death: How To Find A Form With Two Specific Custom Forms On It

[Doug_Den_Hoed__AtAppStore]

You know the feeling you get when, during an online meeting, your screen share shows the "tunnel of death" with your desktop repeating over and over as you flush, embarrassed and frustrated, to scramble to figure out a way to make it stop?

I noticed a similar feeling when, upon trying to change a calculation on a custom form today, Workfront reported "There's a slight problem

[That] field is used in a multi-form configuration, if you would like to change this formula you will need to remove this field and replace it with a new one containing the desired calculation."

What that means is that -- somewhere within my Workfront environment -- there's an Affected Object attached two different custom forms that BOTH have the field I'm trying to change on them, and -- therefore -- I can't change my formula in the custom form I'm working on (e.g. 1+1=2), because it would conflict with the formula in the field on the other custom form, even if the other formula is wrong (1+1=3).

Fair enough...but how, exactly, can I then find this Affected Object? And what if there are more of them? And once I find them all, what do I do to get around this?

So! After an hour later of checking my notes, wf-pro, help, community, and noting that growing Tunnel Of Death feeling, for my own reference, and to spare you someday, here's how I escaped:

• look up the Field and note every Custom Form on which it is used (e.g. Form A, Form B, Form C) for the object type of interest (e.g. Issue)
• on each of those Custom Forms, create a brand new, separate, temporary checkbox parm with a single value of Yes, defaulted to Yes (e.g. _TEMP A on Form A, _TEMP B on form B, _TEMP C on form C)
• Save each Custom Form, effectively "tagging" any existing objects with "Yes, I am attached to Form A (and/or Form B, and/or Form C)"
• under Advanced Search, look for every possible combination:
  • _TEMP A = Yes + _TEMP B = Yes + _TEMP C = Yes (none, in my case)
  • _TEMP A = Yes + _TEMP B = Yes = Yes (none, in my case)
  • _TEMP A = Yes + _TEMP C = Yes (Aha! TWO, in my case)
  • _TEMP B = Yes + _TEMP C = Yes (none, in my case)
• Open each of the objects found and REMOVE one of the two forms (e.g. the one with 1+1=3)
• With that done, try changing field's formula again (e.g. 1+1=2)...which now WORKED in my case, since there were no more conflicts
• Drop the _TEMP custom parameters, having served their purpose
• Save, print, laminate, and post this for the next time you get that feeling

Regards,

Doug

[DavidRu1]

Well Done and Thank you for the effort! Dave Rulon Savannah, GA 912-644-2452

[SkyeHa]

You're so smart! I kind of wonder if the temp param should maybe just be a permanent param, given the number of people who are always wondering what form's on what object. (Or what form is not on what. e.g. _TEMP C is null)

I mean, could it work in that sense?

[Doug_Den_Hoed__AtAppStore]

Thanks Skye,

I did consider that, and in My Town (where I run things), I would be comfortable doing so, likely using a convention creating a parameter called "FORMNAME Form A" to keep them all organized, as a checkbox with "Yes" beside each, then judiciously applying them once-and-only-once on every custom form.

In the real world, though (where I ruin things), suspecting that others might not have applied the convention diligently, I'd probably stick with the _TEMP approach to guarantee that they exist only once, where I just put (and needed) them, and then remove them afterwards.

I'd add that I've personally only hit this 2-3 times (thank goodness) in the 6 or so years since multiple custom forms were introduced, so...meh: _TEMP it is, for me.

Regards,

Doug

[JenniferGa1]

Hi Doug –

This may be a very uneducated question but I am a little confused. I have a calculated field on my custom forms that is causing issues. Each project form needs these 2 calculated fields "Requested Deliverables & Quantities" and "Final Deliverables & Quantities". In each form, the formula is different because the fields I am catenating only exist on that form. To give you an example, we have one form with design deliverables and another video deliverables. It's my understanding that I can use the same calculated field on each of these forms and change the calculation, per this article https://experience.workfront.com/s/article/Add-calculated-data-to-a-Custom-Form-936956366 (please see the last section titled "About using an existing calculated custom field on a new Custom Form"). However, I am getting the error message you describe when I try to apply these fields to my form. Any thoughts?

[Doug_Den_Hoed__AtAppStore]

Hi Jennifer,

What you're describing -- wherein each of the two calculated parameters can have a different formula on each custom form in which it's used -- is correct, useful, and as designed.

Where I hit some trouble (and suspect you may have, too), is where there was at least one item (e.g. Project, Task, Issue, etc.) "somewhere" within my Workfront environment that had at least TWO custom forms on it, each containing the same calculated parameter (and formula). Attaching the additional custom form was a mistake, but is what prevented the formula from then being updated...until I hunted them (two items, it turned out) down and removed the extra form, as per my previous post.

I suggest you do likewise.

Regards,

Doug

[JenniferGa1]

Thanks, Doug! Jennifer Gambacurta Energy BBDO Inc.

[Sheri_Whitten]

Thank you for naming your posts so creatively, Doug! I had saved this post before I needed it. I didn't quite understand it at the time but the name hooked me 😅 I thought, yep this sounds like something I should bookmark. Fast-forward many months later, and I ran across the "multi-form configuration" error and had no idea what it was. I opened a support ticket and thought they'd just give me a nice simple explanation on how to fix it. HA! After trying to find the duplicates within 1,522 rows of an exported spreadsheet (my conditional formatting formulas failing me), I thought, there has got to be a better way! I'll see what the Community has to say. Lo and behold, the answer was here all along. Lesson learned. Again. Check the community first!

And, of course, thanks for the excellent tip! I ended up having 13 projects with the offending calculated field and was able to get them straightened out. There should be a disclaimer when you create a calculated field, "Double check your formula carefully, because if you ever want to change it, good luck!" 😉

[Doug_Den_Hoed__AtAppStore]

Ah, yes....you’ve divined the method to my madness, Sheri. Delighted to hear it was of use. Regards, Doug