How long does the 'updated' flag for Incident Table persist?

[FJH-CoreTech]

When an Incident record in a table is updated, a flag is set denoting the action.

How long does that flag persist?

Reason for question:

I am using Zapier to share information about Incidents in ServiceNow with ConnectWise PSA.

I can trigger a Zap in ServiceNow on an Incident record being 'new' or 'updated'.

'New' does not appear to persist very long, as capturing 'new' works fine.

There is an issue capturing 'Updated' Incidents, as the record updated flag seems to persist for an extended time, resulting in any update to a ServiceNow Incident triggering a slew of captures.

Ideally, I would like to capture an 'update' then turn off the flag or, at least, delay trying again until the 'update' flag is turned off by ServiceNow system.

Hope this makes sense...

[Tony Chatfield1]

HI, unfortunately your question is not clear.
OOB the 'new' state of an Incident persists until an assignee is set for the record, then the Incident moves to a state of 'In progress'.

If an 'update' flag is being set in your SNC instance then I would suspect this is a local customization, and as the community has no visibility of your configuration it is not possible for us to evaluate this.

If you are using a 'GET' query to pull data from ServiceNow then I would be looking at the sys_updated_on time stamp,

and would GET any record updated since the last GET query was run.

If you are posting from ServiceNow then I would trigger a PATCH or PUT whenever an SNC record is updated, the easiest way to do this is to trigger integration with flow or an after update BR

[FJH-CoreTech]

Sorry to be confusing. Maybe I can simplify my issue. We have case where someone creates an Incident and assigns it to, for example, "Security Support". On review there, someone realizes it should be assigned to us "CoreTech Support", so they change Assignment Group and click on 'Update'.

Zap we have on ServiceNow recognizes 'updated', and because of new assignment group, kicks off building a Ticket in our ConnectWise PSA.

This is fine, but, next check by Zap, same conditions, kicks off building another new Ticket, etc, etc. Nice loop effect.

So, what I am trying to figure out is what I can have Zap check in ServiceNow Incident to prevent 'loop'.

I see there is a field called 'Reassignment count' that increments, but does not really help me.

I am not a ServiceNow expert (I am in our ConnectWise PSA), so looking for something in an Incident table record/row that I might use as a check (filter) to prevent 'loop' building new tickets after an assignment change. 

I was hoping that the 'updated' flag perished, so maybe I could delay checking for updates a bit.

Hoping this makes more sense. Sadly, I am working in Zapier, not directly at the API level.

[Tony Chatfield1]

Hi, I would think that key to this is storing a unique identifier (normally the sys_id\GUID) from the ServiceNow record against any record that you create and then before your platform creates a task from a ServiceNow record it should be checking it's 'active' records for the ServiceNow unique identifier, only creating a new record there is no existing match.
OOB ServiceNow sys_updated_on and sys_updated_by will always reflect the last user and time that the record was updated. There is also a field 'sys_mod_count' that shows the number of updates made to a record, but this probably will not help as it will be incremented by any record update.