to create the exact replica of problem table

[nitinku]

Hi,

I am developing the exact replica of problem table and my table is almost about to end but, I'm stuck in one thing like in problem table we have UI actions buttons to change the state of problem . but in my custom table i want to create same UI actions with the proper functionality, I see the OOTB UI actions to get the reference but I didn't get it because in original UI actions there is lots of script includes are created and some ui pages and dilaogues too. so Help me to solve this problem if anyone......

Thank you 

[Ankur Bawiskar]

@nitinku 

but why to replicate?

[nitinku]

In my organization they gave me an task in which i have to replicate this so that's why i do , you have any solution for it?????

[Tanushree Maiti]

Hi @nitinku 

Replicating the Out-of-the-Box (OOB) Problem table is not at all recommended . Deviating too far from baseline creates massive technical debt, negatively affects storage licenses (custom table limits), and leads to difficult upgrade cycles. 

1. Deviating from OOB (Technical Debt)

• The "Why": ServiceNow's OOB Problem Management is based on ITIL best practices. Replicating it means you manually recreate states, business rules, and integrations that ServiceNow natively updates with every release. 
• Best Practice: Leverage OOB features first. If you need unique fields, use Dictionary Overrides, configure Form Layouts rather than creating standalone duplicates. 

1. 2. Storage License & Subscriptions

• Custom Table Quotas: If you create an entirely new standalone table in a custom Application Scope (App Engine Studio), it counts against your licensed custom table limit. 
• Cost Implications: Overusing custom tables can lead to unbudgeted licensing fees for your organization. Utilizing the existing OOB Problem table keeps your storage footprint within your core ITSM license. 

1. Upgrade Issues

• Maintenance Headaches: When you upgrade your ServiceNow instance, OOB tables receive automated updates, bug fixes, and new features. Replicated custom tables will not receive these updates. 
• Skipped Updates: If you radically alter OOB scripts and replicate them, your future upgrades will encounter Skipped Updates, requiring manual developer intervention and longer testing cycles. 

Note: Duplicating the Problem table causes confusion in reporting and breaks the automated, out-of-the-box incident-to-problem lifecycle. 

Actionable Alternatives:
Instead of a full replica, Configure the Form: Add custom fields directly to the OOB Problem table to capture your specific business requirements.

[GlideFather]

ahoy @nitinku,

you can create a new table that extends the problem table it will inherit all the configurations, notifications, permissions, fields, scripts... but why would you do that?