Best Practice and or suggestions welcome... Having multiples of the same field on a single custom form?

[JohnSe1]

note my example is generic not actually the fields but to help make it more common logic hopefully....

Use Case: On a single custom form to have multiples of the same FIELD USE CASE. Example: Let's say you were a car rental agent, and you wanted to have a CF field for Driver. BUT you may need to have on occasion the need to provide a 2nd and 3rd driver. And to make this more real life each driver has a deductible dollar amount.

I know I can use form logic and create CFs for Driver, Driver 2, and Driver 3; and CFs for deductible - and it "works" to collect the information... BUT I find it messy and well just bad design for anyone using the data after submitted. Creating views in reports is not pretty... and creating combined views using a collection approach I think will work just fine. Only gotcha is collection views are more traditional database views and not the cool Workfront report view where users can manipulate the data....

My work around idea - and where I was hoping to pick our collective hive mind....

is to create 2 additional custom forms <Additional driver 1, Additional Driver 2 etc> and use the same field on each custom form - so that the data model is intact and laws of WF Custom Forms isn't broken?!? Or would it be? I can test this - but curious if anyone has gone down this path prior.

Lastly open to ideas as I might be blocking myself for no reason...

thank you all and please stay safe!

[Doug_Den_Hoed__AtAppStore]

Hi John,

Nice try, but if you add the same field ("Additional Driver") to multiple forms ("Additional Driver 1", "Additional Driver 2"), Workfront will consider all of the "Additional Driver" fields to be the same and "point" them at the one-and-only parameter value in the database. Towhit: although you can add John via the Additional Driver 1 form, when you then add Doug via the Additional Driver 2 form, Doug will overwrite John.

Your first (yucky) approach is a common workaround (Additional Driver 1 = John, Additional Driver 2 = Doug, etc.) and those so inclined might soften the blow by adding form logic to "reveal" each Additional Driver section only when it applies (e.g. "Add Additional Driver 1" checkbox...click..tah dah...)

Another potentially more elegant (albeit frowned upon by purists) is to consider leveraging the natural one-to-many relationship that does exist and does allow custom data at the Issue level (or Task, or Project for that matter): Expenses. To risk this road less traveled, each Additional Driver would be a special Expense object under the Issue that captures Additional Driver, Additional Driver License, etc. resting assured that because each is its own separate row, Doug would never overwrite John.

I've taken the latter to extremes over the years, with highly satisfactory results (including charting...mind...blown...). Good luck!

Regards,

Doug

[JohnSe1]

Doug -- I actually left that out of my write up "on purpose" as to not drive an answer. With that I agree with your better answer of adding a sub task (or issue) and prior to that since this has a dollar amount tide to the ask... using Expense module as a way to add line after line. Though I wasn't sure how WF tracked expenses per task (as all of these tasks will live under a single project) BUT I get your frowned on view, this does create a high amount of overhead for the user and requires more training etc etc...

Assumed the database table WF creates for the task would see a collusion with multiple fields of the same ID. Thank you for saving me much time.

I was as many hoping I was doing it wrong :-(

as always you have been great! Hope all is well...

John