Your service desk sends a customer an update. A few moments later, a new request appears in the queue:
Automatic reply: I am away until Monday.
The reply is not asking for help. An agent still has to open the ticket, read it, make sure nothing important is buried inside, and close it.
One ticket is a small interruption. A steady stream of them becomes avoidable churn. Real customer work now shares the queue with messages that nobody needs to answer.
Closing a clear out-of-office reply is easy. The hard part is doing it repeatedly without hiding a genuine request.
The question behind every one of these tickets is the same: does somebody need to answer this, or can it safely leave the queue?
Why did Jira create the ticket?
Your agent understands “I am away until Monday” immediately. Jira sees a message arriving through the email channel.
JSM does filter many automatic replies, bulk messages and delivery failures. Those checks rely on technical signals sent with the email, including its headers. The words an agent reads and the signals Jira receives are not always the same.
A subject can say “Automatic reply” without carrying the header Jira expected. That is enough for a person to recognise the message, but not always enough for Jira to filter it.
If the same kind of email keeps becoming a ticket, check one example in JSM's processing log. It can show how Jira handled the message. Atlassian documents the incoming email checks and where to find the logs.
The next similar ticket may need an answer
An automatic reply is not the only email that can become a new request.
A customer may reply to an existing conversation, but Jira may fail to connect their email to the original ticket. Jira normally uses the request key and email threading information to make that connection. The sender also needs permission to comment.
If one of those checks fails, a genuine customer reply can arrive as a new ticket. From the queue, it may look like another duplicate or stray email. A person is still waiting for help.
That is why a broad subject rule is risky. It can remove noise by hiding a request for help. An agent needs to judge the ticket from the full message, not the subject alone. When an admin changes the email setup, they need to test both an automatic reply and a genuine customer response. Atlassian's duplicate-request guide explains the threading checks.
Review first. Automate when the pattern is clear.
A safe workflow starts with the decision an experienced agent already makes:
- Read the whole message. Look for a question, a problem, or anything that needs a reply.
- Keep the real work. A genuine request stays in the queue, even if it arrived through an unexpected route.
- Close the obvious noise. A clear automatic response can leave the queue once you know nobody needs to act.
- Watch the pattern. If the same messages keep returning, investigate Jira's email handling and decide what can safely be automated.
This approach remains useful even if you never install an app. It replaces a blunt subject rule with a clear question about the work inside each ticket.
AutoReply Guard makes the decision repeatable
AutoReply Guard checks new requests created through the JSM email channel. It reads the subject and message text, then sends possible automatic replies to one review queue.
Start with one project in Review only. Each flagged request explains why it is there. Your team chooses Keep when somebody needs to act, or Close when nobody does. Review only closes nothing automatically.
Every suspected automatic reply still waits for a person. You learn how the app reads your service desk before you let it close anything. That matters because your suppliers, customers and connected systems will not all use the same wording.
When the results make sense and the project's setup checks pass, the app can close requests that meet your automatic-closing rules. Uncertain matches still go to Review.
The boundary is deliberate. AutoReply Guard acts after Jira creates a request. It reads the subject and message text, but not email headers. It does not change Jira's incoming filters or stop Jira's first acknowledgement. It does not check replies added as comments to existing requests.
Back to the out-of-office ticket
The next time “I am away until Monday” becomes a new request, your agent should not have to solve the same puzzle from scratch.
Jira continues to filter the messages it can identify. AutoReply Guard handles the next decision after a request is created. Once automatic closing is enabled, requests that match your rules can close without an agent repeating the decision. Uncertain matches and genuine requests stay visible.
Does this ticket need an answer—or is it avoidable churn?
Start with Review only. Check what the app flags and why. Automate only when its decisions match your team's judgement.
View AutoReply Guard on the Atlassian Marketplace, or use the setup guide.
This is part two of our AutoReply Guard series. Part one introduces the app. Next: how to review a suspected automatic reply without closing a genuine request for help.
