No sys_class_name on extended table when installed or loaded from an update set

[jbenedict]

I am wondering if anybody else has seen any issues with packaging a scoped application where you have a base table and extended tables from that base table.   I had no issues with setting up the application in my development environment but once I made the application available for install to other SN instances or I loaded my application from an update set the base table is missing the sys_class_name field.   This introduced issues for me for I was also loading data records from this table and without the sys_class_name field the records were not getting setup properly.   After install or update set load all it took was a simple update to the base table definition in order for the sys_class_name to be added but this caused further issues with my loaded records.

Here is what my base table looked like after install of my application in the target ServiceNow instance (same behavior if I load it via an update set).

When loading through an update set I would get added errors due to the lack sys_class_name field, these look like:

For now, my workaround is to omit my data records from my application install and then via instruction make an update to the base table definition and then lastly load the data records after the table has been updated to contain a sys_class_name field.

Thanks.

[The SN Nerd]

I think it is normal for Scoped Tables to have no sys_class_name from the Table view.

I have checked my scoped tables and they do not have it either - although I am able to reference this field in code though.

Each scoped record pairs with an Application File (sys_metadata record) which has a table.

Looks to me like every table field is broken - not just sys_class_name. I think the problem is larger than just sys_class_name...

I think something else has gone horribly wrong. I've never tried to use an extended table in an application though.