When to extend core tables in HRSD

[Jordan Mccann2]

Hello,

Has anyone else encountered an issue where too many custom fields are being added to the core HRSD tables?

My customer's core tables have 200+ custom fields for various HR Services. This has led to many UI policies hiding these fields from other HR services on the same table. It has become a chore to manage these fields, and all the UI policies and ACLs created. Usually, I would suggest having a "core" table be used for all "shared" fields and then extending that core table for use cases where many custom fields are needed. This would allow anyone who needs those custom fields to use the extended table, while anyone who doesn't can use the core table.

If I have the benefits table and I need to add 100 services to that table, and each service wants two custom fields, and let us assume none of the custom fields can be shared, then I now have 200 custom fields on that table with potentially 100-200 or more UI policies and client scripts. Do you know if this is the intended approach, or is there a better way to approach this problem? As it is currently built, I can't see how the COE model doesn't become a mess and is almost impossible to maintain. 

I was not the customer when all this was implemented, and all the custom fields were added. Let us assume all the fields have a valid and critical business need tied to them. I know normally, I would push back on this much customization, but that ship has already sailed. 

My initial thoughts would be to extend the COE tables in a meaningful way to make maintaining these tables easier, but I have read in other posts that this might have unexpected behavior.

Thank you,

Jordan

[Dan Sirucek]

I would be interested in your decision. I am in the process of considering creating an table as an extension of HR Profile. The values that it would be for is specific to supporting Onboarding and only used during the onboarding process. 

I do not see the value in using addition custom fields on HR Profile as they will not be maintained once the pre-hire becomes an employee. 

[Suzanne H]

I didn't create any new tables but created new columns on the other existing tables such as sn_hr_core_operations, sn_hr_core_benefits, sn_hr_core_payroll etc. You receive an error message when deleting columns from the sn_hr_core_case table but that is the only way to free up space on that table. You have to update case forms, reports and anywhere the deleted field was and add the newly created field. There really is no way to migrate, you have to delete from one table and then create a whole new field on another table, so you lose the history ie. responses on the columns that are now deleted. It is extremely time consuming and I wish it hadn't come to that. It was shocking to me that there was a limit and I was surprised we had reached it. I agree with you that the other tables could reach the max as well. It would be nice if this was something that ServiceNow could warn you about before it happens.