Why incidents getting created twice with same number & other all fields?

[Ankita Kolhe]

Hi Community,

I have spent so many time in this but still not able to get why this is happening. All fields value are same but difference is in time stamp.

Following things I checked:-

1.Inbound Email Actions(which is not there for incident)

2.Insert & Stay UI Action(which is not there for incident)

3.Checked activity logs (seems to be fine)

Compared History Calendar for this two records. But it's weird, details for one record is empty for one of the user updates while for other record, history seems to be the fine. Is this the issue with duplicate incidents? I'm not sure.

Any response is appreciated .Attached is the screenshot.

Thanks,

Ankita

[Prince Arora]

@Ankita Kolhe ,

Can you make this BR active false and raise an incident for service portal with the same user just to debug the issue?

If it only generates one incident, it means that the problem stems from that single Business rule.

If my answer solved your issue, please mark my answer as ✅Correct & 👍Helpful based on the Impact.

[Bert_c1]

Hi,

Best practice for the above is to use 'current.setWorkflow(false);' before the 'current.update();' to prevent BRs from running again on the record.

https://developer.servicenow.com/dev.do#!/reference/api/utah/server_legacy/c_GlideRecordAPI#r_GlideR...

Since the affected record was created back on 2022-11-16, there will be no node or database log entries to determine why the duplicate was created.  If you see recently created 'duplicates' then the source can be determined.   What happens if the 'if (gr.next()) {' fails?  Seems some testing is needed.

[Ankita Kolhe]

Hi @Bert_c1 ,

I can't use current.setWorkflow(false) as it restricts other BRs or flows to execute.So that's not a good approach I believe. is there any other way to achieve. 

@Ankur Bawiskar Could you please help me on this?

Thanks,

Ankita Kolhe

[Bert_c1]

You need to test, as PRINCE_ARORA suggests. And I suggest you make the BR run "before" (with a high order value) and remove the 'current.update()', since you don't want to follow Best Practice with "After" BRs.  Or do nothing, test, and review what is in the node log file about the BR execution.