Clarification and Solution Request for Dual "Is Virtual" Fields in ServiceNow

[Miralem]

Dear ServiceNow Team,

I hope this message finds you well.

Today, we discovered an interesting issue in our ServiceNow instance. We noticed that there are two different "Is Virtual" fields present:

Is Virtual (Virtual): This is an attribute in the Configuration Item (CI) table cmdb_ci_computer and its child tables (e.g., cmdb_ci_server, cmdb_ci_win_server). This field is used by Discovery to differentiate between virtual and physical computers.

Is Virtual (u_qs_cmdb_ci_hardware_is_virtual): This appears to be a custom (Quick Start) field that was likely introduced before the out-of-the-box "Is Virtual" field was added. It is used by CMDB catalogs and other automations like CI Wizard but not by Discovery.

We are trying to understand the rationale behind having both fields in the HLAG account. Specifically, we are interested in the logic behind the creation and use of the custom/Quick Start field.

The presence of these two fields has led to several issues:

Inconsistencies across forms: Sometimes the out-of-the-box "Is Virtual" field is available, while other times the custom field appears. In some cases, both fields are present, which is confusing.

User uncertainty: Users are unsure which field to update.

Data inconsistency: Users may update one field, thinking it is the other, leading to inconsistent data.

Customer complaints: Customers use both fields interchangeably and often report confusion and dissatisfaction.

We would appreciate it if you could:

Explain why both fields exist in our instance.

Provide any historical context or logic behind the creation of the custom/Quick Start field.

Suggest a solution to resolve the confusion and inconsistency caused by these dual fields.

We look forward to your insights and recommendations on how to address this issue.

Thank you in advance for your assistance and prioritizing this matter.

Best regards,

Miralem Husanovic

[Mark Manders]

Really? You have a custom field field on a custom table and you want us to explain to you why it is there and how it works? 

It exists because someone created it. Get that someone to explain to you why, including the logic and context. How can we ever do that for you?

Solution is to use the OOB field, which will only be on the hardware-extended tables. If you need it on others, you will have to use a custom table.

[Miralem]

Yeah really ! maybe i write my question wrong or my topic in a different way - there is a qs field like is virtual and then someone created a field manualy as the same as is virtual - question is why when you choose on the Server the tick box is virtual sometime its used the qs field and sometime the manualy created ?
 Also this was a question related for some issue that some one have in the past or simular logic used for this kind of solution - like did they use some BR or ACL for such as cases like this

[Mark Manders]

Again: we can't tell you why something was custom build on your instance. You would need to involve the people that created it if it was not documented. We don't have access to your instance and we can only guess to why it was done in this way. It could have been a terrible developer, or maybe it was the most revolutionizing process back then. 

[Chelsea Ruel]

I think we went through a similar situation, with a completely unrelated custom field.

1. A custom field was created, and behaved as expected with no issues.

2. Sometime later ServiceNow added the same field with the same name to the same table.

3. Then this field starts having some unpredictable behaviour, some things don't work. 

@Miralem If I'm understanding this correctly, I'd suggest raising a case with ServiceNow to help sort out what's happened. The issues caused for us were fairly minor and easy for us to fix, but it sounds like your situation might be causing more issues. 

@Mark Manders If I'm understanding this correctly, it's not about understanding the behaviour of a custom field created by an internal employee - they need to understand the interaction between a custom field and an overlapping new field created by ServiceNow.