Nomenclature - Plugin ids, Properties, Table names

[Anish Reghu]

I am talking about the way names are prescribed to the plugins, properties and Tables in CSM.

While some refer to as com.snc. | com.sn_ | com.glide | com.snc.csm | Some plugins although are CSM plugins do not use the com.snc.'csm' - THIS LEAVES THE READER VERY CONFUSED.

The properties are somewhat better - Most of them start with sn_customerservice_

And finally the table names - some start with csm_ | some start with sn_csm_ and around 20 of them start with sn_customerservice_

Sorry, if it sounds disturbing, but isn't this adding a lot of confusion - Why not follow a standard nomenclature?

I can understand being in the platform that it is evolving, and the nomenclature might have kept evolving as well which is why we see the changes. But, as nomenclature flavors change, ServiceNow should have also done some work to ensure that these names are all in tandem. Suggestions?

Regards,

Anish

[Anish Reghu]

NO replies?

[Maik Skoddow]

Hi @Anish Reghu 

I'm not sure what your expectation is as you describe the current state which isn't changeable anymore and furthermore in this community are mainly users like you and me online.

And I suppose you already know the reason for some inconsistencies. The ServiceNow platform has been around for several years now. And during this time a lot can happen: changing technologies, fluctuating ServiceNow employees and so on.

So what exactly is your issue, we can support you?

Koind regards
Maik

[Anish Reghu]

Thanks Maik.

The concern here is that - if one wants to remember the plugin names, table names or even the properties, the naming convention followed in the platform does not let the reader do it.

If All plugins follow a specific naming convention,

If All Table names could have followed a naming convention,

If All properties could have followed a certain naming convention (mostly they do, but not all)

Associating topics or context to respective table names, properties and plugins would have been a easy job.

Hope that clarifies.

Cheers,

Anish

[Maik Skoddow]

Hi @Anish Reghu 

Yes, I see your point, but I still do not know how to help you 😞

Given how rapidly ServiceNow, as well as all other major platforms / ecosystems, are evolving, all I can say is that ServiceNow's documentation is quite consistent.

And there are things that simply cannot be changed. Keep in mind that unlike other PaaS / SaaS providers, ServicevNow offers each customer their own physically separate instance. This makes it impossible to perform comprehensive refactoring

Kind regards
Maik