This customization DOES NOT come across in update sets! If you make this change you need to make it across all of your instances manually as soon as you verify the result in a dev or test instance.
S
ervice-now allows you to use and create extended tables to help organize your database structure.  Out-of-box, there are 2 really important places that you’ll need to understand this setup.  The first is the ‘task’ table (which includes incident, problem, change_request, etc.) and the second is the ‘cmdb_ci’ table (which contains every table in the Service-now CMDB).
One of the nice things about this type of arrangement is that it allows you to set up fields or columns on these tables that can be unique to a single table (‘caller_id’ on the Incident table) or available to all extensions of a parent table (‘short_description’ on the Task table).  You can see if a table extends or is extended by another table by using the table schema map.

If you’re not careful when working with tables that are set up this way, you can get yourself into a little bit of trouble.  Fortunately it’s not that difficult to work your way out of it most of the time.  The biggest thing to be aware of when you’re creating fields on an extended table is to know what table you’re working on and what table(s) your new field should be available to.

If you do make a mistake, the easiest thing to do is just to catch it early and re-create the field.  If that’s not possible then there is a command you can run that promotes a field from an extended table to a parent table.  The function should be run from ‘System Definition -> Scripts – Background’ and works like this…