Hi,
We have a workflow that creates a SNOW ticket based on identity attribute changes. In a situation, the workflow is triggered multiple times with the same data resulting in duplicate tickets within a few minutes. So prior creating a tickets, Can we query servicenow from the workflow to check if the ticket already exists for the identity? Please advise how to incoporate the flag in the workflow.
Can you give more details? Why is the workflow being trigger more than once?
During workday aggregation, identity attributes were updated mutliple times consecutively with the same data in a single run that inturn caused the workflow to trigger each time the trigger logic was met.
The same attribute was updated multiple times during the same aggregation?
yes, that’s correct. The same attributes were updated mulitple times and one of them triggered the workflow
Hi @ssel
In ServiceNow, add a custom text field on the ticket table (incident / sc_req_item) called:
u_idn_dedupe_key
Make it UNIQUE (so ServiceNow rejects duplicates).
In the IDN workflow, build ONE string that represents “this exact ticket”.
Example:
||
(No timestamps.)
Workflow logic:
A) SEARCH ServiceNow:
“Do I already have a ticket where u_idn_dedupe_key = this string?”
B) If YES → stop. Do nothing.
C) If NO → create the ticket and set u_idn_dedupe_key = this string.
That’s it. One key per real change, one ticket max.
What exactly does this mean?
And how do subsequent workflows know how to build that same value?
By “build ONE string”, I mean: create a key that will be IDENTICAL every time the same “real-world event” happens, so I can safely dedupe on it.
Example (one ticket per identity + one attribute change):
dedupeKey = ||
Why “no timestamps”:
If you include a timestamp, the key is different on every run, so the pre-check will never find the first ticket and you’ll still get duplicates.
How other workflows “know” the same value:
They don’t “discover” it automatically — I standardize the recipe and reuse it.
so i have those options:
In ISC workflows, I can build the key with operators:
The UNIQUE index on u_idn_dedupe_key is the safety net for race conditions (two runs at the same time): ServiceNow will reject the second insert.
How would this handle an identity attribute changing more than once? There are valid use cases where that would happen like department, title, etc. The way you’ve put it together, once one attribute change occurs for an identity, no subsequent ones will be allowed for that identity.
If the key is only identityId, then I’d block any later tickets for that identity which is bad approach .
Use a repeatable key like:
identityId|attributeName|newValue (optionally add effectiveDate/window if we want grouping).
Same change fired twice → same key → will skip the second create.
Attribute changes again → different key → new ticket is allowed.
This approach assumes identity attribute values never repeat after their initial change. There are plenty of valid circumstances where attribute values will change to a new value then change back to their original value. Attributes like department, job title, manager, etc. can all have this happen.
Agreed — that can happen. The key isn’t “identityId|attribute|newValue” alone if you need to distinguish repeated values.Include the event’s effective timestamp (or a change-id/window) in the key, so “back to the same value later” becomes a different key:
identityId|attributeName|newValue|effectiveDate (or |YYYYMMDDHH)
so
the knob: exact change vs. change-per-window.
You said earlier not to use timestamps
Thanks for pushing on the edge cases 
I should’ve been clearer on “no timestamps”.
I meant: don’t use a “now()” timestamp that changes every run, or the lookup will never match.
If values can repeat, add a stable occurrence marker:
identityId|attribute|newValue|effectiveDate (best)
or |eventTimeBucket (minute/hour).
Same burst/retry → same key → duplicate blocked.
Same value later → different key → new ticket allowed.
How would you generate this effective date?
I you don’t “generate” an effective date in ISC.The trigger payload doesn’t include one (it’s just attribute/old/new), so the clean option is to pull the timestamp/ID of the actual change event from Identity History, then use that as the occurrence marker in the key.
My Workflow will looks like that
Trigger fires (identity + attribute + old/new)
HTTP call to /historical-identities/{identityId}/events and take the matching latest event for that change
Key = identityId|attribute|oldValue|newValue|eventId (or eventTime)
That avoids “now()” timestamps, and it also allows repeats later without blocking them.
The identity history response timestamp is iso8601 which presents the same potential matching problem as using now()
But what I’m more interested in is how can we be sure by retrieving the latest event that it matches to our workflow execution? Shouldn’t we need to do some matching on attributes changed to ensure we’re selecting the correct event?
Mark I agreed on both points.
So for this symptom , I’d keep it simple
what is your insights on this ?