Carlos Camacho

        The Choice table is used internally by the platform and depending on the payload of an operation, for performance reasons the platform can decide that it is better to drop the table and insert all the values instead of perform updates on specific records.       When we insert a new record in a table, a new sys_id is generated. If we have the Choice table as a reference to provide choices for a particular field in our table, these choices will be lost every time the platform decides to recreate the Choice table.       A simple way to avoid this problem is to create a field of  type Choice  which indirectly uses the Choice table but it is the right way, or we can create our own table to maintain the Application choices.       Recently I received the mission to do exactly this: create a private choice table for an Application.     The problem       A long time ago, the platform allowed a developer to choose the Choice table as a reference.       As a consequence, old custom applic

     The Choice table - which has the internal name sys_choice - is used internally by the ServiceNow platform every time we create a field of type Choice and specify the available choices.        Points to remember when creating a choice       Always use only lowercase and underscores to form the Column name.         The Column label is what appears for the end user so you are free to use uppercase and spaces.       Use the same logic to create a choice. The value is internal and should contain only lowercase and underscores. The Label is what appears for the end user so you are free to use uppercase and spaces.        What you should never do       Never specify the Choice table as a reference in a Reference field. For example:       A reference field stores the sys_id of the corresponding record in the reference table. Since the Choice table is a core internal table, its behaviour is different from custom tables and the sys_ids can change.       The problem: when a sys_id in a refer