New fields in customer scoped applications ... adding the u_ prefix???

[Zod]

Hi All,

when creating a new scoped application, newly added fields on scoped tables do not the the u_ prefix by default. Anyhow recommended to add them?!

[Chuck Tomasi · Accepted solution]

Hi.

I don't use them. Never have, never liked u_. For global it makes sense to avoid conflict the ServiceNow fields. Example, you create u_due_date, SN created due_date.

Since there is NO CHANCE of conflict in a scoped app, because YOU created it, the u_ isn't needed and I don't feel like adding my fields manually just to have u_ in there. There's no point. I know, when I'm a scoped app that I don't have to worry about when to use or not use u_ prefixes. It's liberating in a way - at least to me.

[Jon Barnes]

Yay! I was so pleasantly surprised when I built my first scoped app and found that the u_ was not auto-appended. And exactly! it didn't need it. I love it so much.

So fully agree on this.

[Wallace Roets]

I fully agree with Chuck.

However I do believe there are exceptions, if this is your own app as Chuck mentioned, i.e. you are the developer, then I don't see the need of using 'u_'. If you are enhancing a store app (i.e. a scoped app which you bought on the store), I still use u_ to ensure future changes to the store app doesn't collide with mine.

[cynlink1]

I encountered this issue recently, and wanted to share with the community:

KB0787421  - Name conflicts may be introduced by new OOB fields if a custom field having same name has been created in Studio on same table hierarchy

Workaround

If after an upgrade or plugin update you experience an unexpected behavior related to a custom field that does not have a custom 'u_' or scoped 'x_' prefix. please validate if an OOB field with the same name has been added on the table hierarchy (parent or ancestor table) and contact ServiceNow Technical Support for further assistance. 

Related Problem: PRB1287819