Extending the Incident Table

[goochg79]

Hi All,

We are working in a MSP domain seperated enviroment.

Because of this we now have serveral different fields sat on the base incident table, across the contracts, some of the fields are not relevant or even reusable to each of the clients.

We are looking at having a base incident table and extending this for each client so we are able to add additional fields to this without affecting the all version of the incidents and using UI policies to hide the non required fields.

We have basic additionals which will affect the all customers as part of ITIL and follow the same process, so these will remain or be added on to the base Incident Table, IE Major Incident, Security Incident, etc.

Does anyone have any experience with this or guidance, or are we looking at this the wrong way and should be using the UI Policy and Client Scripts to bend the the OOB incident to each Clients need?

[sergiu_panaite]

I don't have that much experience with MSP domain separated environments, but be aware that if your task table is flattened (Task Table Flattening - ServiceNow Wiki) you actually have one big task table physically and all extensions are just logical within the application. Adding many extended tables can lead to some limitations on the database side (mainly due to the number of columns which for example is limited on MySQL InnoDB engine to 1000), so I would think twice about this.

Regards,

Sergiu

[PeterWiles]

It's been a while since I worked on a domain separated instance but can't you create a separate views for those that need different fields? No ui policies/script includes are needed.

[goochg79]

Thanks Both,

Sergiu - the DB limitiations are not a worry in this instance, we are trying to keep the numbers low.

Peter - We currently have seperate views running but as we are adding more customers the number of fields is going up and the number of views, it becomes long winded to add a new view as we are trawling through more and more fields, I thought it would be simpler to have a base (OOTB) incident and when we get a new client extend that to include there custom fields

[PeterWiles]

You could have one view and then use the "Read" ACL to limit the field to the domain/customer or what ever logic you wish.

You could then extend the logic to have another table control who has access to what field so you don't have to update the ACL if a new customer wants the field.

As I say a lot, in ServiceNow, there are 10s of ways of doing everything so there is no "right" answer (most of the time). I will depend on what the additional fields are and how you manage the process/customers/instance.

Could you potentially end up having duplicate fields on the numerous child tables that are the same thing? i.e. 4 customers request a "third party ref num" so you create an additional field on each of the child tables.

If a customer asks for a new field, would another customer not benefit from that field?

What will the admin overhead be from creating a new child table?

Would you use the "base" incident table for all customers unless they wanted additional fields?

Pete