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 https://github.com/elastic/kibana/issues/147353#issuecomment-1420443751, 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 2023-01-11 16:37:48 not requested 3aabc2b34f524200b47e48f18110c702 1970-01-01 00:00:00 0 1970-01-01 04:35:37 16537 37955be387ff0d5070fecbf6cebb35c6 0 2023-01-19 11:00:01 5fc72f4f4fbd6b000bbc97411310c761 f66b14e1c611227b0166c3a0df4046ff phone RL108157SR01 The windows service tomcat needs to be restarted on the host RL108157SR01 0 1 7 false true 1 INC0416568 2023-01-11 10:37:46 37955be387ff0d5070fecbf6cebb35c6 2 0 0 2023-01-11 15:13:23 5fc72f4f4fbd6b000bbc97411310c761 2 Apache Tomcat 9 windows service stopped on RL108157SR01 7 incident SVC-ElasticITSM 2023-01-11 10:37:46 global / 8622e98e8758299070fecbf6cebb3560 11 SVC-ElasticITSM 2023-02-04 10:38:08 INC0416568 false proceed cancel 2

[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 https://github.com/elastic/kibana/issues/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 https://github.com/elastic/kibana/issues/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 https://github.com/elastic/kibana/issues/170164 with the extra steps.