When is it acceptable to create custom fields in a global vs. scoped application?

[alexcha]

Our organization started using ServiceNow to replace Remedy about 3 years ago.   Instead of reviewing existing processes to take advantage of the ServiceNow platform, a number of requirements were created to make ServiceNow an extension of Remedy.   As a result, our instance became heavily customized.  

Instead of upgrading our current instance to the next release, we may have the opportunity to start with a new out-of-box instance.   In preparation, I was hoping to get guidance mainly from a development perspective on functionalities surrounding Scoped Applications.  

Our goal is to avoid creating custom fields on OOB tables in the global scope (e.g. sys_user, sys_user_group, incident...).   I was thinking about creating a scoped application that extended the OOB tables (to contain our custom fields).   While testing this approach in my personal development instance, I found that:

• OOB tables will still need to be updated in order to make them extensible
• Challenging to utilize OOB relationship tables/functionalities.   For example, if we were to extend the sys_user and sys_user_group tables in our scoped application, it looks like we won't be able to utilize the sys_user_grmember table (because they still reference the OOB tables).  

With my inclination to not touch anything OOB, it seems like I may be creating more work/complexity.   We then started thinking about the purpose of a scoped application and when it's appropriate.   Our team started thinking it would be okay to create custom fields, business rules, UI policies, etc... on OOB tables in the global scope as long as we're not changing the functionality of what those tables were intended for.  

I was hoping to get feedback from anyone who went through something similar and what the agreed upon approach was.  

[Kalaiarasan Pus · Accepted solution]

Your final approach seems the reasonable and most widely followed approach. I haven't worked much on scoped apps and so I can't comment much on that.

Few tips that I can give about implementation part.

• Do not touch out of the box scripts etc unless absolutely necessary. You will end up adding more risk and the upgrade cycle would always be troublesome.
• Carefully evaluate the fields before adding on base tables. Review and decide if the fields needs to go on parent table like task or can be created on child table or better as a custom table that has relationship to the child table. Database views are you friends and make use of them wherever possible.
• Avoid using UI pages in design as this tend to require updates whenever UI changes in ServiceNow.
• Avoid any DOM manipulation to do UI hacks.

[Chuck Tomasi]

To add to what Kalai wrote... there are a lot of documented best practices. The doc team is aware they need some updates (to include scoped best practices.)

Reference:

ServiceNow Wiki: Technical Best Practices

[alexcha]

Chuck,

Thank you for the update and also for the link.  

[alexcha]

Kalaiarasan,

Thank you very much for the reply and also for the information.