How to create a custom choice field and then use in multiple times within a table (i.e. different field labels)?

[ty_roach]

I'd like to create a custom choice field one time, call it 'approval_options', with values:
Not Responded
Approved
Needs Discussion
Rejected

Next I'd like to create custom fields (more than one) that use these same choice values. For example, my custom fields that would use this same choice set are fields that I will call:
Customer Care
Cyber Security
Engineering
Operations
Business Office
Board

I could brute force do this, making custom choice fields for each of the above types (including all the color/style updates), but that seems like alot of work. Is there a way create a custom choice field and then use in multiple times within a table (i.e. different field labels)?

[andrew_kincaid]

Well... I suppose I was thinking that Task [task] was an easier table to remember where the drop-down choices are coming from; however, during an upgrade, if there are any changes to the Task [task] table, it will be skipped. I suppose a better method would be to make a new table (not extended from task) that would only hold your custom choice drop-downs. You wouldn't make this form available in any Application or Module but could keep a link to it as a Label or as a bookmark in the Power Edge (if you are using UI11). I've also created custom applications before to hold items like this and only make the application available to admins.

You could create a new table "u_custom_fields" then add "u_approval_options" to that and then always use the "u_custom_fields" table when you need to re-use a drop-down and its choices. What I was initially thinking was to not put a drop-down on an extended table (like Incident) and re-use it from there because I think that could be confusing and someone might not realize that "u_approval_options" on Incident is being re-used somewhere and they might change the options thinking they are only modifying something in use on Incident.

Using a new, non-extended table solves the issue of a core table being skipped during an upgrade (like Task) and solves the issue with someone potentially changing the choices if you had the drop-down originating from an extended table (like Incident.)

What do you think about that approach?

Andrew Kincaid
Technical Consultant
ServiceNow

[ty_roach]

Sounds good. I didn't realize that customizing a default table (like task) would cause it to be skipped during an upgrade. So, I guess it does make sense to create a custom table putting only the fields we want to re-use it. In this case (ie., we create a custom table) does that mean we need to create a related link to it from a form that we want to personalize with our custom fields?

[ty_roach]

I did it, but colors (personalized styles) created with the custom approval options are not coming thru.

[andrew_kincaid]

You do not need to link to u_custom_fields in any way other than to personalize the dictionary on your new choice field and set the Choice table and Choice field - in essence, that is all the "linking" you need.

As far as styles go, they only apply to the form they are defined for. If you create a new choice field on Incident and use u_custom_fields to re-use the choices, the style will have to be defined for the Incident table. It will not inherit style by using the Choice table/Choice field option in the dictionary.

Andrew Kincaid
Technical Consultant
ServiceNow

[ty_roach]

Bummer about the inheritance limitation. So I can create a custom choice field and use it repeatedly (good), even within the same form. That's what I'm going to do - one defined choice, multiple instances used within the same form: custom approval (u_approval_options) for Board, Cyber, Engineering, Operations, Business Office and Customer Care.

So do I have to create customized style for each of those 6 instances?