Thank you, Susan.

My question is more about the architecture and data model surrounding HRSD. This model makes sense until you use it. There is no way to prevent HR from needing additional fields to help manage different services. This is why we can extend tables. I am not worried about the table restrictions. I am worried that COE tables do not scale very well since you are trying to jam everything into this very limited data model.

Let's say we can have an infinite amount of HR services and each HR service could need custom fields. We do our job and ask hard questions and each field is unique and needed. That means we will hit the table caps on fields eventually. Not only that, but for each Service added we need to develop naming conventions around UI policies, client scripts, and custom fields to help manage this customization. We also now have a more complicated time pulling reports because we have hundreds of custom fields.

My question is why we "don't" advise extending HR tables to make the application more scalable. What is the reasoning behind siloing the work to just the OOTB tables and why was it built in this restrictive manner? I would much rather design my own data model than be forced into one that makes it hard to manage the more I use it.