Is Extending Incident Table being Recommended Approach?

[VCN]

We have mandatory requirement to add more custom fields specific to each Line of Business for Incidents, the custom fields will be more than 20 as if now but it may grow further in future. 

We do not want to add these fields directly on the Incident table, looking to create a custom table by extending the Incident table as we may have to write some business logics on these newly created custom fields for each Line of Business.

I would request you to share your experience and recommendation approach for this requirement.

1. Is it fine to extend the Incident table (OOTB extensible is false for Incident table)?

2. Is there any other way we can implement this without extending the Incident table followed these fields should be displayed for Incident and allow to create Incident (without writing any business logics on Incident table for these custom fields), also all the Incident lifecycle and functionalities should be working? 

Note: We understand that ServiceNow don't recommend customizations but would like to understand the solution implemented with best practices followed given we need to work on this requirement to have more custom fields for a Incident.

[Dr Atul G- LNG]

Hi @VCN 

1. Is it fine to extend the Incident table (OOTB extensible is false for Incident table)?

Atul: As per my knowledge and experience it is not good to extend Incident table, instead of look option to add new fields in task table or new table extend from task.

2. Is there any other way we can implement this without extending the Incident table followed these fields should be displayed for Incident and allow to create Incident (without writing any business logics on Incident table for these custom fields), also all the Incident lifecycle and functionalities should be working? 

Atul: Check on Business Unit or CMDB tables.

[VCN]

Thanks for your inputs on this.

[-O-]

The statement

custom fields for each Line of Business

is a clear indication that you are heading in the wrong direction.

So while adding one or two very incident specific fields to the table could be acceptable, 20 LoB specific fields, whether it is on Incident or an extension of it, is clearly wrong.

You should consult with someone versed in (RDB) schema normalization to guide you on how to store that data in a better way, so that the no. of columns will be much less and it will not need adjustment whenever the structure of LoBs changes.

[VCN]

Thank you for your inputs on this.