CI list is empty after submission of incident

[Cally]

Sometime within the last week or two, something has happened/changed to where after an incident is created & submitted, you can not change or add a configuration item as the reference list appears empty. When a ticket is generated via inbound email action, we are not able to go back into the incident to add one because the reference list appears empty and typing in the CI just returns an "invalid reference" response. However, when an itil user creates a new incident, you are able to view and select from the list of all available CI's based off of the category/subcategory before you submit it. After submission of that incident, you can not go back and change the CI because the list shows "no records to display". 

What is even more strange to me is that if you go back into older incidents created before this issue started, you have the ability to change the CI's on those.

The only recent change we have made within that time frame (that we are aware of) was an update set containing changes and additions to field mapping for users, but there were no issues in our dev instance when creating an incident and going back to change a CI or to add one (maybe there wouldn't be since it does not sync up like prod? I'm not sure).  Any help or advice would be greatly appreciated! 

This is the CI list showing up before an incident is submitted: 

This is the CI list showing empty after an incident is submitted and trying to change it:

[Stephen Sturde]

Hi Cally -

So this only happens when the record is created by inbound email action, correct?

Looking at the screen shot of your form where it's blank, I see that "carte" is populated as a valid selection in the CI value already. If you clear that value, and save the record, does that open up the list?

From what I can read in the screen shot of the Ref qualifier, we have:

javascript:['incident','problem'].indexOf(current.sys_class_name+'')==-1?:'operational_statusNOT IN' + new OpsStatusFilter('cmdb_ci').by('CreateTask').join()

It looks like there may have been another image file, but the link to it is broken.

Breaking the Ref Qualifier down a bit, what we're filtering here is:

• ['incident','problem'].indexOf(current.sys_class_name+'')==-1
• • checks to see if the current record is NOT an incident or problem. The result is a true/false response
• ?:
• • Conditional operator. essentially acts as an 'if' operator
  • In our case if it evaluates true, no filter is applied.
  • If it evaluates to false (meaning it is an incident or problem) then we apply the filter
• 'operational_statusNOT IN' 
• • first part of our filter is a string query that removes records where the operational status field is NOT in a state defined by the next portion...
• +
• • Concatenates the next part of the string to our operational status check
• new OpsStatusFilter('cmdb_ci')
• • Calls a script include record entitled 'OpsStatusFilter' with the parameter of what appears to be just the table name.
• .by('CreateTask')
• • function called inside of the 'OpsStatus' script include entitled 'by' with parameter of 'CreateTask'
  • You'll need to look in this record to know what statuses are removed. These are available in the application navigator under System Definition > Script Includes. Search for 'OpsStatusFilter'. Inside of the script look for a function called 'by'
• .join()
• •  pulls together all of the above elements for the reference qualifier to have a coherent query

[Cally]

Hi Stephen,

I really appreciate you taking the time to break down the Reference Qualifier, that was very helpful in understanding what it is doing. Weirdly enough, I found that the issue had to do with the Dependent Field tab value. Somehow that got changed to "company" when the choice list options are determined by the "class" field. I am confused on how this got changed in the first place. I know when we did the update set that our developer added field mapping to "company" to the users but I did not think doing that would cause this issue so it is still a mystery to me. Thanks again for all your help!

[Stephen Sturde]

Hi Cally - 

I'm glad you were able to solve it! Let me know if you need any additional help.

[Cally]

Thank you, will do!

[Scott Wright1]

I know this is an old post, but it helped me figure out an issue I was seeing just like this.  OOTB, the dependent value is set to company, which helps in a multi-domain setup.   It works OOTB as long as the incident doesn't have the company set.  In my case, we have incidents being created by an integration that is setting the company field.  That caused it to fail to show any CI's because none of the CI's have a company value set.  You may have had something similar.

Of course, removing the dependent field of company would resolve it as long as you aren't multi-domain.  You'd have to remember to add it back if you ever went multi-domain.  I think a more sane option would be for ServiceNow to leave it blank unless multi-domain is configured.

Lesson learned and this thread helped me figure out what was going on.

Thanks,