Custom user field vs OOTB

[esebasti]

Hey folks this is a very broad question but I was wondering if there is any best practice documentation on adding custom user fields to a table?  There are many tables in ServiceNow that are used by multiple modules and we have a need to add some additional fields for some of the functionality that our business requirements dictate. Now that being said there are some OOTB fields on tables that might work for our requirements any are not currently being used by some of the modules that we have. Our organization is going to be expanding as we grow and implementing additional models and functionality as time goes one. So basically I am wondering if I use the OOTB fields that are currently not being used, will this come back and bite me in the butt later when we implement more modules or should I play it safe and create the fields that we need to satisfy the business requirements?

For the most part I am looking for some ServiceNow best practice docs on the subject.

Once again I know this is very broad and thanks for any insight anyone has one custom user fields

e

[Shweta KHAJAPUR]

Hi,

For ServiceNow best Practices refer below link,

https://developer.servicenow.com/app.do#!/catlist/technical_best_practices?v=jakarta

Regards,

Shweta K

[Sagar Patro]

For a broad question, there is a broad answer. Like it 🙂

[Sagar Patro · Accepted solution]

Whenever you have this question popping in your head, you have at least 3 ways to do it:

1. Create new fields on the table

 I believe this is the least risky step because the data is saved in the new independent columns on which there is no script dependency and you can run the show the way you want.

2. Use the existing unused fields for good.

    We have done this multiple times instead of creating new fields. The first thing to keep in mind while using any OOB field for your need is not just the type of the field but also the business requirement of that field being present on the table. The second thing to keep in mind would be how hard/effort would it be if later you have to migrate the data to a new field. In most cases, it is simple to migrate the data. And not to forget the last thing, verify if there is any script especially BRs if there is any running related to that field/column

3. Extend a table a create new fields in the new extended table.

This would really depend on what kind of use case scenario you have. In your case, if you are having a very different class of user with a lot of properties to it. You may go for it. OOB a lot of base tables are not "Extensible(cannot extend)", user table is one of it. But I do not see any issues extending it as well. The user created on the extended table would also have the same login capabilities.  Unless you have a really good reason, you should not do this.

Recommendation

If I was you, I would have gone for #2 approach. It is a best practice to avoid creating any new field unless you have a good reason.

Hope this is helpful.

Make sure to mark it Helpful and Correct if it was.

Good Luck!

[esebasti]

Thank you for all your feedback. this has really helped.

e