Automate Jira issue creation from Slack messages in Make.com, with deduping via Google Sheets, field mapping, and a reply back to Slack.

Introduction

Your team already coordinates in Slack, but Jira still depends on someone doing the “ticket creation” step manually. That is how requests get lost between channels, details get shortened, and duplicates get created when two people ask for the same fix.

This is a practical Cross-Platform Automation (XPA) pattern: when a message hits your Slack channel with the right structure, Make.com creates the Jira issue, logs an idempotency key, and then posts a confirmation back into Slack. By the end, you will know how to build a Slack-to-Jira workflow in Make.com that stays duplicate-safe even when runs replay.

What You'll Need

Slack: permission to read messages in the channel you monitor, and permission to post back into the channel (or thread)
Jira: permissions to create issues in your target project and issue type
Make.com: a scenario with Slack and Jira connections authorised
Google Sheets: one spreadsheet with edit access to store your idempotency ledger
A consistent Slack message format (example provided below) so field extraction does not turn into a mess

How It Works (The Logic)

The workflow is simple and intentionally robust:

Slack trigger → filter and parse fields → compute an idempotency key → lookup key in Google Sheets → create Jira issue only if not logged → write key + Jira issue key to the ledger → reply in Slack with the Jira link.

Trigger → parse → dedupe (ledger lookup) → create → log → confirm

Step-by-Step Setup

1) Create a Slack “intake marker” and message template

Make one rule your team can follow. For example, require messages to start with [JIRA] and include key-value parts.

Use a template like:

[JIRA] summary: Website login failing for new users | priority: High | labels: bug,auth | description: Users get a 500 error after signup.

What you gain is predictable parsing. What you prevent is “random Slack text” turning into Jira tickets with missing summaries.

2) Build the Google Sheets dedupe ledger

Create a spreadsheet with a tab named jira_ledger and columns:

idempotency_key
slack_ts
slack_channel
slack_author
jira_issue_key
created_at

This sheet is your idempotency ledger. It is the same operational idea behind “digest logging” workflows, where you only notify once per item, not every time the scenario runs. If you want the digest pattern reference point, see how to send a daily Airtable status digest to Gmail.

3) Create a new Make.com Scenario

In Make.com, create a new Scenario
Add the Slack trigger for “new message” in a channel (pick the channel first)

Keep the trigger scoped to one channel to avoid processing casual chat.

4) Filter to only messages meant for Jira creation

Add a filter immediately after the Slack trigger.

Example conditions:

Message text contains [JIRA]
Optional: author is in your internal team, or the channel equals your dedicated intake channel

If you do not filter early, you will create Jira issues for anything that matches your parsing logic by accident.

5) Parse the Slack message into fields

Use Make.com text operations to extract:

summary
priority
labels (comma-separated)
description

A practical approach is to parse based on your delimiters:

Split the message by |
For each segment, split by :
Trim whitespace

Gotcha: decide what happens when someone forgets priority:. For that case, set a default priority like Medium in Make.com.

6) Compute a stable idempotency key

You need a key that uniquely represents the intent and will not change between retries.

For Slack message triggers, a reliable pattern is:

idempotency_key = slack_channel + ':' + slack_ts

Why this works: Slack message ts (timestamp) and channel identify a single message event.

7) Lookup the idempotency key in Google Sheets

Add a Google Sheets step to search rows in jira_ledger where idempotency_key equals your computed value.

Then branch logic:

If found: stop, skip Jira creation
If not found: continue to create Jira issue

This prevents duplicate ticket creation when Make.com retries or when you rerun executions.

8) Create the Jira issue

Add the Jira action Create issue with mappings:

Project key: your Jira project
Issue type: Bug or Task depending on your process
Summary: parsed summary
Description: parsed description, and include Slack context (author and channel)
Priority: map High, Medium, Low to your Jira priority scheme
Labels: if your Jira connector supports arrays, convert labels into a list, otherwise join in the Jira label format

9) Write back to the ledger after Jira creation

After Jira returns jira_issue_key, add a Google Sheets Add row step to write:

idempotency_key
slack_ts
slack_channel
slack_author
jira_issue_key
created_at

This step is what makes the workflow replay-safe.

10) Post a confirmation reply back in Slack

Add a Slack action to post a confirmation message back into the thread.

Message example:

“Created Jira: ABC-123 for: Website login failing for new users”
Optional: include priority and labels
Include a Jira URL if your Jira connector returns one, or construct it from your Jira base URL

If your Slack connector returns a thread context value, use that so the requester sees it where they posted.

11) Test with deliberate duplicates

Do three tests:

Post one valid [JIRA] message, confirm one Jira issue is created
Edit and repost similar content, confirm it creates only when it is a new message event
Re-run the Make.com execution for the same message event (or force a retry) and confirm no new Jira issue is created, because the idempotency key already exists in jira_ledger

12) Turn it on and monitor the first week

During the first week, check:

Parsing output is correct for summary and description
Priority mapping matches your Jira configuration
Google Sheets lookup is finding existing keys
Slack confirmations are going to the right thread

Real-World Business Scenario

A mid-sized SaaS support team used this setup for bug intake. Engineers and support leads posted requests into a dedicated #support-requests channel using the [JIRA] template. Make.com created a Jira ticket immediately, wrote the idempotency key and issue key into jira_ledger, then posted a reply back in Slack.

The outcome was predictable ticket creation and fewer duplicate tickets. More importantly, the request context stayed intact because the Slack message structure forced people to write a real summary and description.

Common Variations

1) Route by labels to different Jira projects

If labels includes auth, create the issue in the SECURITY project. If it includes billing, create in FINOPS. Implement this with a router after parsing.

2) Add an “assignee mapping” table in Google Sheets

Create a second tab in the same spreadsheet, like assignee_rules, containing label to jira_component or assignee mappings. Then look up assignment rules based on the parsed labels.

3) Add escalation for High priority

For priority: High, also post an extra Slack alert to #urgent-ops while still creating the Jira issue once.

The system you just built

You built a Slack-to-Jira XPA in Make.com that turns structured Slack intake into real Jira issues without duplicating tickets. The core is the idempotency ledger in Google Sheets, plus strict parsing and early Slack filtering.

If you want this adapted to your exact Slack message format, Jira projects and issue types, and your team’s dedupe rules, Olmec Dynamics builds these automations for real businesses. Start with Cross-Platform Automation (XPA) and you can see what we do at Olmec Dynamics.

How to Automatically Create Jira Issues from Slack Messages Using Make.com