nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do you prevent Jira Automation from creating duplicate issues when the same event is triggered m

Milena_8z3gza

Hi Atlassian Community!

I’m working with a Jira Automation rule that creates an issue based on an external event/webhook.

The rule works correctly, but occasionally the external system sends the same event more than once, which can result in duplicate Jira issues being created.

I’m considering storing an external unique ID in a custom field and checking with JQL before creating the issue.

Something like:

"External ID" = "{{webhookData.id}}"

If no issue is found, then create the new one.

Is this the approach you normally use for this scenario?

I’d also be interested to know if anyone uses entity properties, issue properties, or another method to make Jira Automation more idempotent.

Thanks!

Accepted answers

Jovânio Junior

Hi, welcome to the Atlassian Community!

Yes, using a unique identifier from the external system is usually the safest approach.

I’d store that ID in a Jira custom field and, before creating anything, run a Lookup issues action using JQL such as:

"External ID" = "{{webhookData.id}}"

Then only create the issue when:

{{lookupIssues.size}} = 0

This way, even if the webhook is sent twice, Jira can recognize that the event has already been processed.

I prefer a custom field for this because it also makes troubleshooting easier — admins can search for the external ID directly in Jira.

The important part is making sure the external ID is truly unique and always sent with the event.

For integrations, I think of this as an idempotency check before creation, and it prevents a lot of duplicate-ticket problems.

All comments

Jovânio Junior

Hi, welcome to the Atlassian Community!

Yes, using a unique identifier from the external system is usually the safest approach.

I’d store that ID in a Jira custom field and, before creating anything, run a Lookup issues action using JQL such as:

"External ID" = "{{webhookData.id}}"

Then only create the issue when:

{{lookupIssues.size}} = 0

This way, even if the webhook is sent twice, Jira can recognize that the event has already been processed.

I prefer a custom field for this because it also makes troubleshooting easier — admins can search for the external ID directly in Jira.

The important part is making sure the external ID is truly unique and always sent with the event.

For integrations, I think of this as an idempotency check before creation, and it prevents a lot of duplicate-ticket problems.

Josh

Yes — storing an external unique ID and checking before create is the standard pattern, and it works well.

Custom field (e.g. “External ID”), single line text.
On webhook received: Lookup work items with JQL
"External ID[Short text]" ~ "{{webhookData.id}}"
(use the exact custom-field searcher syntax your site shows in JQL autocomplete).
Condition: {{lookupIssues.size}} equals 0 → then Create; else Log “duplicate skipped” (optionally comment on the existing issue).
On Create, set External ID = {{webhookData.id}}.

Also dedupe at the source if you can (idempotency key). Webhooks can fire twice within a second — Lookup is still the right guard. Avoid “compare two lists in memory” without Lookup; JQL against the field is what scales.

If Lookup races (two webhooks at the same instant), a second create can still sneak through; rare, but if it matters, have the external system retry with the same id and treat the second as update-only.

Surya Bhagavan Ravuri - CTE

Hi @Milena_8z3gza

Yes, using a custom External ID field and checking for an existing issue before creating a new one is the most common approach.

Configure the rule to:

Search for an issue where External ID = {{webhookData.id}}
If found, update the existing issue or stop the rule.
If not found, create a new issue and populate the External ID field.

This is simple, easy to audit, and effectively prevents duplicate issues caused by repeated webhook events. Entity properties can also work, but a custom field is typically the easiest solution to maintain.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management