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

[EnesOzdemir]

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 stateResponse SLA is running for a secondschanges are reverted

[jfernandes1]

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. 

[EnesOzdemir]

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]

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.

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'})

```

[jfernandes1 · Accepted solution]

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.

[EnesOzdemir]

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?

[ABurt]

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.

[EnesOzdemir]

Thank you very much @ABurt @jfernandes1