SLA changes that are made by field change scripts are getting reverted

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

SLA changes that are made by field change scripts are getting reverted

L3 Networker

Hi, I have a a field trigger script assigned to a status field. When it changes, the script stops an SLA and starts another and these are Time To Assignment and Response SLA respectively. I have one tenant that refuses to keep the changes meaning that it sets the SLAs and then within a second all is reverted. I can clearly see it on the incident page that Response

SLA changes for less then second and goes back to its previous state like it wasn't run in the first place.

 

 

When the script is run manually from CLI, everything is fine.

 

This is how I am setting the SLAs

```

demisto.executeCommand("stopTimer", {"timerField": "timetoassignment"})
demisto.executeCommand('startTimer', {'timerField':'responsesla'})

```

 

I am not sure if it helps but this tenant is created after the server is upgraded from 6.2.0 to 6.6.0

 

first statefirst stateResponse SLA is running for a secondsResponse SLA is running for a secondschanges are revertedchanges are reverted

1 accepted solution

Accepted Solutions

L5 Sessionator

Hi @EnesOzdemir, I was able to locate the ticket and I think I understand the issue better now.

 

Yes, this is limitation of the platform. To prevent a know issue with DB version synchronisation since 2 different versions of the incident are sent to DB at the same time. The limitation was document here - https://docs.paloaltonetworks.com/cortex/cortex-xsoar/6-2/cortex-xsoar-admin/incidents/incident-mana....

 

You will need to de-select the "Run triggered script after incident is modified" option.

View solution in original post

7 REPLIES 7

L5 Sessionator

Hi @EnesOzdemir, Can you see the same results in the warroom? Meaning for each screenshot above there should be corresponding "Incident info and changes" entries.

 

I've not seen this behaviour before. It might be that another fieldTrigger script is running. You can check by enabling debug logs. If you still cannot find the root cause, I would suggest raising a support request since this might require investigation of the logs. Could you also confirm that the script in ending as a success? Failed fieldTrigger scripts prevent field changes. 

L3 Networker

Hi, thank you for helping me. yes  I can see the results in the warroom. I believe the script isn't failing because I don't see any errors. The support told me that this issue is related to product implementation so they sent me here.

 

 

EnesOzdemir_0-1653286519023.png

 

 

L3 Networker

I think I found the root cause of the problem. It's related to this part of the field. When I uncheck this all the SLAs are working properly.

EnesOzdemir_0-1653300400132.png

 

I had no problem with this feature on version 6.2.  As I have said before I am running only the following commands to make sure it isn't my script that's causing the problem.

```

demisto.executeCommand("stopTimer", {"timerField": "timetoassignment"})
demisto.executeCommand('startTimer', {'timerField':'responsesla'})

```

 

L5 Sessionator

Hi @EnesOzdemir, I was able to locate the ticket and I think I understand the issue better now.

 

Yes, this is limitation of the platform. To prevent a know issue with DB version synchronisation since 2 different versions of the incident are sent to DB at the same time. The limitation was document here - https://docs.paloaltonetworks.com/cortex/cortex-xsoar/6-2/cortex-xsoar-admin/incidents/incident-mana....

 

You will need to de-select the "Run triggered script after incident is modified" option.

L3 Networker

I don't quite understand what "Run triggered script after incident is modified" mean. I used to think that I wouldn't be able to access the value after the field is modified if I don't select that option(with it I thought I was forcing the script to run after that very field is changed and modifications took place). I deselected it and it's working now.

 

Why the option worked on 6.2 I don't understand it either.

 

> To prevent a know issue with DB version synchronisation since 2 different versions of the incident are sent to DB at the same time

 

Can you please elaborate on this one because this tenant is created after the upgrade?

 

 

 

If the field-change triggered script were to error to any reason (and you didn't have "Run after" box ticked) then the field would not be changed. This can be an issue for mirrored incidents or incidents where the data is automatically updated. To prevent this, the "Run after..." box can be checked to ensure that the field is updated before running the script. This ensures that the field is modified correctly even if there are errors.

 

If your field-change-triggered script is not going to modify the incident in any way, then it's good to tick this box. This avoids any failure on updating fields and can still happily error out if it needs to. If it DOES modify the incident what happens is:

- Incident is modified by the user / automated function and saved to a version (from version 1 to version 2, for example)

- Field change triggered script runs and modifies part of the original incident (version 1)

- Committing the changes errors because the version the script changed is earlier than the one that is ready for commit. This still results in the original change being made, but the change being made by the script is dropped.

 

 

L3 Networker

Thank you very much @ABurt @jfernandes1 

 

  • 1 accepted solution
  • 3269 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!