ServiceNow connector updates closed ServiceNow ticket and not opening or reopening old ticket.

[S3l3ct3d]

Kibana version:
8.5.2
Elasticsearch version:
8.5.2
Server OS version:
Elastic Cloud
Browser version:
108.0.5359.99
Browser OS version:
Chrome

Describe the bug:
So we are utilizing a couple of actions on our Observability Alerts, which are working well. So my well I guess concern/complaint is that with the ServiceNow integration for an action to open a ticket works, but there is no way to just "update" the already "OPENED" ticket accurately. Let me explain a little more. So in the integration for the action you can add in the {{ruleID}}:{{alert ID}} in the "Correlation ID (optional)" section which will update the [This is the kicker] "ORIGINAL" case/ticket that was created. But, let say you go through the workflow, fix/resolve the issue, and close the ticket/case in ServiceNow. When this particular alert happens again it should at least do one of two things, "re-open" the previously closed ticket/case, or create a new ticket/case since the other one is closed. It does neither one. It just goes ahead and updates the previously closed ticket.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[pmuellr]

@cnasikas @shanisagiv1 I'm not up-to-speed on where we are with more elaborate work flows like this, but I don't think we have anything in-plan for this, at the connector level. And wondering whether maybe cases is impacted, or perhaps even "solves" this problem (or someday WILL solve the problem).

[cnasikas]

This is an interesting workflow. Before pushing we can check the status of the case and reopen it. The new behavior will impact cases but we can make it configurable and let the user decide if they want to reopen or not the incident. I wonder if there is a context variable we can use to open a new issue after a period of time has passed. For example {{ruleID}}:{{alert ID}}:formatDate({{date}}, "YYYY/MM/DD").

[S3l3ct3d]

Good morning, I can give more insight and context to this if needed. As I still have this setup and running to my non production ServiceNow instance. I can test any new configuration that is needed or provide any other information needed. Thanks

…

On Tue, Feb 7, 2023, 03:17 Christos Nasikas ***@***.***> wrote: This is an interesting workflow. Before pushing we can check the status of the case and reopen it. Cases will be impacted by the new behavior but we can make it configurable and let the user decide if they want to reopen or not the incident. I am wondering if there is a context variable we can use to open a new issue. For example {{ruleID}}:{{alert ID}}:getDay({{date}}). — Reply to this email directly, view it on GitHub <#147353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF3LJJ2AYPWZBWCAN5YPUSTWWIHLXANCNFSM6AAAAAAS37H4NY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[S3l3ct3d]

Here are a few screenshots from my ServiceNow Instance showing how the Elastic / ServiceNow connector is updating a "resolved/closed" state ticket.

As well here is the "xml" output for this ticket.

This XML file does not appear to have any style information associated with it. The document tree is shown below.


false
<activity_due>2023-01-11 16:37:48</activity_due>
<additional_assignee_list/>
not requested
<approval_history/>
<approval_set/>
<assigned_to/>
<assignment_group display_value="Restaurant Support - Tier One" name="Restaurant Support - Tier One">3aabc2b34f524200b47e48f18110c702</assignment_group>
<business_duration>1970-01-01 00:00:00</business_duration>
<business_impact/>
<business_service/>
<business_stc>0</business_stc>
<calendar_duration>1970-01-01 04:35:37</calendar_duration>
<calendar_stc>16537</calendar_stc>
<caller_id display_value="SVC-ElasticITSM ">37955be387ff0d5070fecbf6cebb35c6</caller_id>


<caused_by/>
<child_incidents>0</child_incidents>
<close_code/>
<close_notes/>
<closed_at>2023-01-19 11:00:01</closed_at>
<closed_by display_value="Michael Huff">5fc72f4f4fbd6b000bbc97411310c761</closed_by>
<cmdb_ci/>

<comments_and_work_notes/>
f66b14e1c611227b0166c3a0df4046ff
<contact_type>phone</contact_type>
<correlation_display/>
<correlation_id>RL108157SR01</correlation_id>
<delivery_plan/>
<delivery_task/>
The windows service tomcat needs to be restarted on the host RL108157SR01
<due_date/>
0
<expected_start/>
<follow_up/>
<group_list/>
1
<incident_state>7</incident_state>
false

<made_sla>true</made_sla>
1
INC0416568
<opened_at>2023-01-11 10:37:46</opened_at>
<opened_by display_value="SVC-ElasticITSM ">37955be387ff0d5070fecbf6cebb35c6</opened_by>

<origin_id/>
<origin_table/>

<parent_incident/>
2
<problem_id/>
<reassignment_count>0</reassignment_count>
<rejection_goto/>
<reopen_count>0</reopen_count>
<reopened_by/>
<reopened_time/>
<resolved_at>2023-01-11 15:13:23</resolved_at>
<resolved_by display_value="Michael Huff">5fc72f4f4fbd6b000bbc97411310c761</resolved_by>

<route_reason/>
<scr_vendor/>
<scr_vendor_closed_at/>
<scr_vendor_opened_at/>
<scr_vendor_point_of_contact/>
<scr_vendor_resolved_at/>
<scr_vendor_ticket/>
<service_offering/>
2
<short_description>Apache Tomcat 9 windows service stopped on RL108157SR01</short_description>

<sla_due/>
<sn_esign_document/>
<sn_esign_esignature_configuration/>
7

<sys_class_name>incident</sys_class_name>
<sys_created_by>SVC-ElasticITSM</sys_created_by>
<sys_created_on>2023-01-11 10:37:46</sys_created_on>
<sys_domain>global</sys_domain>
<sys_domain_path>/</sys_domain_path>
<sys_id>8622e98e8758299070fecbf6cebb3560</sys_id>
<sys_mod_count>11</sys_mod_count>
<sys_updated_by>SVC-ElasticITSM</sys_updated_by>
<sys_updated_on>2023-02-04 10:38:08</sys_updated_on>
<task_effective_number>INC0416568</task_effective_number>
<time_worked/>
<u_3b2_priority/>
<u_3b2_request/>
<u_ae>false</u_ae>
<u_ae_reason/>
<u_dash_issue/>
<u_hp_case/>
<u_managementgroup/>
<u_pagerduty/>
<u_pagerduty_id/>
<u_proccess_sync/>
<u_string_2/>
<u_system_applications/>
<u_third_party_number/>
<u_tp_id/>
<u_tp_priority/>
<u_type/>
<universal_request/>
<upon_approval>proceed</upon_approval>
<upon_reject>cancel</upon_reject>
2
<user_input/>

<watch_list/>
<wf_activity/>
<work_end/>
<work_notes/>
<work_notes_list/>
<work_start/>

[shanisagiv1]

Thanks for the details @S3l3ct3d it's really helpful! We have plans to upgrade our snow connector for cases soon (with Bidi sync and support more fields, etc). we definitely should address this use case as well. I believe we'll be able to get back to you soon with more details to validate that our plans meet these needs. cc: @cnasikas

[S3l3ct3d]

Good evening, just seeing if there has been any advancement or movement on this?

Thanks,

[S3l3ct3d]

@cnasikas @shanisagiv1 I'm not up-to-speed on where we are with more elaborate work flows like this, but I don't think we have anything in-plan for this, at the connector level. And wondering whether maybe cases is impacted, or perhaps even "solves" this problem (or someday WILL solve the problem).

@pmuellr, I can say that even in "Cases" the does not work correctly either. I have used the cases feature and pushed the case to ServiceNow with the connector, which it does. However, when you update the case in Elastic the case does NOT get updated in ServiceNow. Also when you select the push to ServiceNow (thinking this would update the ServiceNow ticket, it just creates a new case in the ServiceNow platform.)

[cnasikas]

@S3l3ct3d This seems like a different bug in Cases. Can you please go to the first SN incident (INC0661600) and check if the "Correlation ID" of the incident is set to the Elastic Case ID? Can you do the same with the second SN incident (INC0663203)?

Regarding the issue of when the SN incident is closed, I opened this issue to track it #162557 and put it in our backlog. We don't have a specific timeline for this but it should get picked up soon. I will let you know.

[cnasikas]

Related #170522

[S3l3ct3d]

@cnasikas, I have pulled both XML previews from each of the ServiceNow incidents and the correlations ID's are the same on both.
INC0661600.txt
INC0663203.txt

But has you can see in the screenshot, Elastic opened two separate incidents within ServiceNow.

[S3l3ct3d]

@cnasikas , I forgot to add the case ID from Elastic as well. Here it is. 4af59a40-b7ca-11ed-bfe4-f513f2ed861e

[cnasikas]

Hey @S3l3ct3d. I suspect that you do not have the proper cross-scope privileges. Could you please add the following cross-scope privileges (sys_scope_privilege)? This should work for Cases. FWIW, you would still not be able to reopen a closed issue. We are working on it.

You will need first to pick the application scope Elastic for ITSM before adding the cross-scope privileges.

We have an issue with improving our docs #170164 with the extra steps.

[Erikg346]

Did this get solved already?

[cnasikas]

Hey @Erikg346! Not yet. You can track this issue here #162557.