Custom tables recreation in scoped application

[Priyanka Munjal]

Hello,

In our instance, there are 5–6 custom tables that were created in the global scope. Recently, we received a Licensing and Usage Overflow email from ServiceNow.

Now, the we want to recreate these tables within a scoped application.

We are currently using these tables to display content on the Employee Center (ESC) portal, so we are thinking of recreating them under the Employee Center scope.

Can someone please confirm if this is the correct approach?
Should these tables be recreated under the Employee Center scope, the Employee Center Core scope, or would it be better to create a new custom scope for this purpose?

[Ravi Gaurav]

Hi @Priyanka Munjal 

That’s a great question and a common situation when organizations start tightening up their licensing governance.

Here’s how to think about it:

1. Why moving out of Global makes sense

You’re right that custom tables created in the Global scope count toward your custom table entitlement unless they’re part of a licensed app (like ITSM, HRSD, etc.). Recreating them in a scoped app helps control and isolate usage, especially if the content is specific to Employee Center.

2. Which scope to use

You have three practical options:

a. Employee Center (ESC) scope
This scope is meant for the Employee Center portal configuration layer. It’s typically not intended for new custom business logic or data models. If you create tables directly here, they’ll be tightly coupled to ServiceNow’s managed app, which could cause upgrade issues later.
Recommendation: Avoid creating your own tables in the Employee Center scope.

b. Employee Center Core scope
This scope supports the underlying data model and framework for ESC (like content items, menus, and topics). Like ESC, it’s owned by ServiceNow and updated during upgrades. Adding custom tables here is not recommended, as it breaks the separation between your customizations and OOTB code.

c. A new custom scoped app (Best Option)
Create a dedicated scoped application, e.g. LearnNow Employee Content or Custom Content Portal. This is the cleanest and most upgrade-safe approach.

• You can reference these tables from your ESC widgets, pages, or UI Builder configurations.

• They remain isolated from ServiceNow-managed scopes.

• It keeps licensing and ownership clear—everything under your namespace is your responsibility.

3. Integration with Employee Center

Even if your new tables live in a custom scope, they’ll still work perfectly with ESC:

• You can expose the data using Record Producers, UI Builder data resources, or custom widgets.

• Assign appropriate roles and ACLs for portal users.

• If you use Content Delivery (Content Items, Topics, etc.), you can link to your custom data by URL or catalog content type.

4. Migration note

When you recreate the tables:

• Retain the same field names and relationships where possible.

• Migrate data using Transform Maps or Export/Import.

• Update any widgets, content blocks, or flows referencing the old tables.

---

Final Recommendation:
Do not build in the Employee Center or Employee Center Core scope.
Create a new scoped app specifically for your custom tables, and integrate it with the ESC portal through configuration and permissions.

[Ankur Bawiskar]

@Priyanka Munjal 

yes you will have to re-create them as they can't be migrated from global scope to Scoped app

Now they should sit in which Scope EC, EC Core or Custom only you or your technical team can decide as we are not sure what those tables perform or how the access to it is handled etc.

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Sarthak Kashyap]

Hi @Priyanka Munjal ,

All tables in ServiceNow are stored in the sys_db_object table, and changing the scope or application is not possible. You must recreate all the tables in your specific scope.

Please mark my answer correct and helpful if this works for you

Thanks and Regards,
Sarthak