Add fields dynamically on form

[ruzbehv]

Hi All,

I have a form for which users need to add additional fields.   Rather than offer them an "other" choice which limits them to just 1 entry, we want to have a "+" symbol which will allow them to create and name the field(s).   These fields should also be available for reporting.  

Another issue which needs to be considered is when two different people enter the same name as the dynamic field.

Any suggestions?

Regards,

RV

[mduluk]

We had something like this for interface hosts.   There could be several hosts with different attributes.   We ended up makeing a new table for interface hosts and had it as a related list on the interface from.   Then when people needed to add a new host they just created a new item on the related list.   Because this is a new table, it was able to be reported off of.

[tltoulson]

To add to Matt's answer, you could add the Related List as an embedded List (select the List from Personalize > Form instead of Personalize > Related Lists).   If you enable the list editing and the ability to add a new row from the list view, you will accomplish pretty much everything you mentioned.   Unique field names per record could be accomplished via a business rule on the new table.

I would definitely recommend Matt Duluk's answer for this one.

[ruzbehv]

Hi Matt/Travis,

I was looking into the system and see a UI macro 'ui_input_field'.   I was hoping to leverage this to create field by showing a "+" icon that would allow the user to enter the field.

Any thoughts?

RV

[tltoulson]

You could create a formatter using a UI Macro as you indicate.   This would not create fields dynamically in the truest sense.   However, you could store the values from your macro in a long text field (4000+ length).   I would recommend storing as a JSON encoded string as it is the easiest to encode/decode.   In that way, each time you added a "field" using the plus sign on the macro, you would actually be adding a key/value pair to the stored string.

You can see a great example of how this sort of thing is done by looking at a Condition Builder field.   The value is actually stored as an encoded query but it is displayed as though it were multiple dynamic fields.

My preference would still lean toward a separate table and Related List as it is the easiest to maintain.   When building a complex UI Macro / Formatter, you have to consider cross browser compatibility, mobile compatibility, and ServiceNow client code changes.   All of these things are maintained by ServiceNow if you use the Related List method.   Something to consider.