Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Detect 'To' Email Only, Exclude 'CC' in Jira Workflow

Joelle Phung
April 16, 2026

Hi Support Team,

I’m currently working on an automation project for our support service and had a question regarding Jira’s email handling. Specifically, I’m wondering if it’s possible for Jira to detect only the 'To' email address when creating a ticket, and not consider the 'CC' field.

For example, if a customer sends an email and includes us in the 'CC' field but isn't actually requesting support, my current automation rule automatically creates a ticket. However, I’d like to adjust the automation so that it only creates a ticket based on the 'To' email address and ignores any 'CC' emails.

Could you let me know if this is possible, or if there is a workaround to achieve this behavior?

Thank you for your help!

1 answer

0 votes
Marc -Devoteam-
Community Champion
April 16, 2026

Hi @Joelle Phung 

Unfortunately, this setting cannot be disabled there is a suggestion open to track this request at Provide Option To Disable Automatic Adding Of Request Participant When They Are CC'ed in an Email

As a workaround, you can create an automation to clear this field each time is updated.

  1. Trigger: Field Value Change
  2. Action: Edit Issue
    1. Add the "Request participant" field and leave it empty
Joelle Phung
April 16, 2026

Hi Support Team,

Thanks for your response.

I believe there may have been a misunderstanding of my question. My main concern is not about request participants being added, but rather about ticket creation itself.

Specifically, I would like to know whether it is possible for Jira to distinguish between emails where our support address is in the "To" field versus only in the "CC" field, and only create tickets in the former case.

From your reply, it seems this behavior cannot be controlled, but could you please confirm explicitly whether Jira supports this distinction at the ticket creation stage?

If not, are there any recommended workarounds to prevent tickets from being created when our address is only CC’d?

Thank you for your clarification.

Marc -Devoteam-
Community Champion
April 16, 2026

Hi @Joelle Phung 

No this is not an option.

If an email is sent to the mail address linked with your support portal, a ticket will be made.

Jira is not differentiating if this is in the To or CC field of an email.

To setup such a behaviour, you would need yourself to 3rd party mail integrations.

See the Atlassian Marketplace.

Joelle Phung
April 16, 2026

Hi Support

Thanks for your reply and the clarification.

Since Jira doesn’t currently support distinguishing between the "To" and "CC" fields for ticket creation, could you recommend any specific third-party mail integrations or plugins from the Atlassian Marketplace that would allow me to implement this behavior?

It would be helpful to know any tools or integrations that would work with Jira Service Management to achieve this functionality.

Thanks again for your assistance!

Marc -Devoteam-
Community Champion
April 16, 2026

Hi @Joelle Phung 

You could look at Email This Issue or Jira Enterprise Mail Handler

Joelle Phung
April 27, 2026

Hi Support, 

I wanted to share an observation regarding JEMH. From our testing, it appears that JEMH processes any email containing our support address, whether it appears in the "To" or "CC" field, without differentiating between them.

This is important for our workflow because we intend to:

  • Automatically send a first response only if the email is sent directly to us (To field).
  • Avoid automatic responses if the email is CC’d.

Could you advise if there’s a way to configure JEMH to recognize these fields, or is this a known limitation?

Finn Gale
April 27, 2026

Hi @Joelle Phung,

Could you advise if there’s a way to configure JEMH to recognize these fields

JEMHC currently allows users to add additional Address headers to identify a Catch Email Address matches however, it is not possible to remove default (To/Cc/Bcc/Delivered-to) headers. We see this as an improvement and have created an internal ticket to add this feature.

However as a workaround, you could use JEMHC's Scripted Pre-Processing task to remove the catch email address from the email before processing which would provide the outcome you are looking for. You can read more about this feature here:

If you would like more detail, or have any additional queries, please feel free to raise a request with us on our Support Portal, and one of our team will be able to provide some more guided support.

 

All the best, Finn (The Plugin People)

 

Joelle Phung
April 28, 2026

Hi Support,

Thank you for the helpful information on the Scripted Pre-Processing task. I just have one follow-up question: if I use the pre-processing task to remove the catch email address from the email before it’s processed, will this still create a ticket in the system? I’m concerned that even after the catch email address is removed, it might still create a ticket and consume a ticket number.

Thank you

Finn Gale
April 29, 2026

Hi @Joelle Phung,

if I use the pre-processing task to remove the catch email address from the email before it’s processed, will this still create a ticket in the system?

No this will not create a ticket in your system.  You could also conditionally drop or ignore the email as part of the pre-processing task using the 'setOutcome' method which you could read more about here:

To clarify, this would still be counted towards JEMHC capacity usage (as JEMH still has to process the email, only the result is now no issue is created). An alternative approach would be to setup a rule on your actual Mailbox to remove these emails if you did not want them to be processed.

If you have any follow up questions please open a ticket on our Support Portal, and one of our team will be able to provide some more guided support.

All the best, Finn (The Plugin People)

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events