Tunnel Of Death: How To Find An Object With Two Specific Custom Forms On It

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?

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

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?

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

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!" 😉