AutoReply Guard help

When you turn a project on, AutoReply Guard runs the Initial email check. It looks at the latest emailed requests from the last 14 days, up to 1,000 per project, and counts how many matched the automatic-closing rules. After a later settings change it runs again as the Recent email check.

The result appears on the Overview, for example “[n] of [total] recent requests matched the automatic-closing rules.”, with the line This check did not close any requests. Select Show results for each project's detail.

Automatic closing and rule previews wait until the check finishes. If it cannot finish, it is retried at the next hourly check. While AutoReply Guard is paused, the check pauses too and continues when you resume.

When your service desk emails a customer, the customer's mail system sometimes answers on its own: an out-of-office reply, a bounce, a meeting acceptance, or another helpdesk saying it received your message. Some automatic replies arrive as new JSM requests instead of being filtered out. AutoReply Guard checks the wording of those requests.

AutoReply Guard reads the subject and message text. It does not read email headers. It checks new requests created by email. A reply that Jira adds as a comment to an existing request, because the subject names a request key, is not checked.

The rule set includes wording in nine languages: English, French, German, Spanish, Italian, Dutch, Korean, Chinese and Turkish. Coverage depends on the wording; other languages may not be recognised. Unmatched messages can remain ordinary Jira requests. Live automatic-closing tests cover English, French and Spanish. Before you turn on automatic closing, look at the matches from your own messages in Review.

What it does not do:

• It does not email the requester and does not delete anything. Each closure adds one internal note, which only agents can see.
• It acts after Jira creates the request. Jira may still send its first “request received” email.
• It cannot see your inboxes, your SLA goals or your queue filters. The setup steps tell you what to check there yourself.

Each row says why it is waiting, based on what happened to that request.

Show details also shows the full subject when it is long, where the wording matched, and anything that points the other way, for example The message asks a question., The request has attachments. or The requester is not the email sender. Possible repeat of [key] means the same requester sent a similar subject recently; check both requests, because the content may still differ. Other helpdesk's reference keeps the other helpdesk's ticket number.

Keep and Close decide only this request. Under For future requests in the details, up to three actions change what happens to later requests. The same actions appear in a request's details in History.

• Protect requester: requests from this person will not close automatically in this project. Confirm with Add protection; it saves straight away.
• Add requester rule: choose what happens to this person's requests in this category, Send to Review or Close automatically. It saves straight away after you confirm. A rule set to close still sends matches to Review until you preview and apply it. Protected requesters are excluded.
• Disable this phrase: new requests will not be matched using that phrase in this project. It opens a preview first. Existing decisions do not change, and the action is not offered while AutoReply Guard is paused.

Each row shows the Request and its Latest activity: the outcome, then who acted and when, such as by [name] · [time] or Flagged by AutoReply Guard · [time]. A teammate appears by their Jira name, or as “a teammate” when no name can be read. The action at the end of the row is Reopen, Review (for a request waiting in Review) or Open in Jira (when the outcome could not be confirmed).

Filter by Project and Outcome. More filters adds Category, Received from, Received until and Mode when checked (Review only, or Automatic closing on). The dates filter by when the request arrived. Hidden filters keep their values, and the toggle shows how many are active, for example More filters (2). Hide extra filters folds them away. Clear filters resets everything. Load more fetches older requests.

Show details opens What happened: the full sentence, the message excerpt where one was recorded, when it happened, the status before closing, who made the change, and a link to the request in Jira.

Download CSV saves the requests that match your current filters. The page confirms Download started with the file name. The Changed by column holds the teammate's name, not an account ID. Only the newest matching requests per project are included, and the page says so when the file is capped. If the app cannot read every project, no file is downloaded.

History is kept for 30 days on Standard and 180 days on Advanced. Older records are removed automatically.

• The review callout shows how many requests need review, with Review requests to go straight to them.
• Your projects shows each project's state (Automatic closing on, Review only, Waiting for setup, Paused or Permission lost) with one sentence on what happens there, when a request was last checked, and View settings.
• Activity counts requests closed automatically, closed by your team and reopened, for the last 7 or 30 days, by when each was closed or reopened. Reopened requests count only under Reopened.
• Message patterns groups the last 30 days of requests by similar wording, not by who sent them. Each row quotes the message line and says how many requests it covers or how many need review.
• A line asking you to check requests in Jira appears only when the app could not confirm what happened to some requests. View affected requests lists them.

Numbers marked “at least” are lower bounds. The page reads the newest requests of each outcome in each project, so the real totals may be higher. If requests have not been checked for a while, a warning says so.

Choose one of your site's resolutions, or Leave empty. An empty resolution can leave a closed request in queues or SLA rules that depend on resolution, such as an Unresolved filter. If your queues or SLA goals depend on resolution, choose one of the resolutions your site already uses, then check those filters and goals against the status you chose.

The app tests and names each request type separately. Until a type is tested, the check says Finish testing [request type] before AutoReply Guard can close requests of this type. Request types that passed can close automatically; the blocked types stay in Review until their own test passes.

The setup is checked again once a day. If a request type stops passing, for example after a workflow edit, automatic closing waits for that request type. Settings and the Overview say Automatic closing is on for [project], but waiting for setup for [request type]. Select Check settings. Request types that still pass keep working.

Select Check settings to see what to fix. After a workflow change, close and reopen a test request again for each affected request type.

Each project has its own settings. The Project selector and the switch appear on both the Protection and Rules & exceptions tabs. If you choose another project with unsaved changes, a dialog titled Unsaved changes in [project] offers Save changes, Discard changes or Stay here.

When shared settings cover a project, a category shows whether it Uses shared settings or whether This project uses its own setting, and people protected through shared settings are marked From shared settings.

Add wording that helps identify automatic messages in this project, such as your suppliers' auto-reply lines. Under Custom phrases, enter the Phrase (2 to 120 characters on one line), choose its Category and where to Match in (Start of subject, Start of message, or Anywhere in message), then select Add phrase.

Use Test a message to paste a Subject and Message and see whether the phrase matches. With the phrase field empty, it tests the project's saved phrases. A phrase match alone does not mean the request will close.

New phrases send matches to Review. Use for automatic closing opens a preview first. Remove phrase deletes a phrase; if the phrase is used for automatic closing, removing it goes through a preview too.

A requester rule decides what happens to one person's requests in one category. Add it from a request's details in Review or History with For future requests → Add requester rule. Rules appear under Requester rules in Settings, with What it does for each. A new rule sends matching requests to Review. Use for automatic closing lets it close them, after a preview. Remove rule deletes it. Protected requesters are always excluded.

Any change that could close more requests is previewed before it applies. The preview lists affected recent requests under Current rules and Updated rules, as Would close or Would stay open, with a total such as “[n] more requests would close.” It does not change any Jira requests.

• Choose Check requests from: Last 14 days, or Last 60 days on Advanced.
• Apply changes saves the change for new requests only. Requests already decided do not change.
• If the settings changed while the preview was running, run it again before applying.
• A preview needs AutoReply Guard turned on for the project, the email check finished, and processing not paused.

On the Shared settings tab, select Create shared settings. Give it a Name (up to 80 characters) and choose its Projects. It can hold email categories, protected requesters, custom phrases and requester rules. Save with Save changes; Edit shared settings opens it again.

• A project's own category settings take priority. Protected requesters from both lists remain protected.
• Shared phrases and requester rules send matches to Review. They do not close requests automatically.
• Saving rechecks recent requests in the selected projects. Automatic closing waits until those checks finish.
• Shared requester rules come from Import rules with Shared settings as the destination, once the shared settings are saved.
• Editing needs administrator access to every affected project. Anyone else can view it.

On the Protected organisations card, select Add organisation, paste a request in Request shared with this organisation, and select Find organisations. Choose the organisation, select Add protection, then Save changes. Requests shared with a protected organisation do not close automatically.

While this protection is active, requests whose organisation cannot be read also go to Review, because the app cannot tell whether they belong to a protected organisation.

1. Select Import rules.
2. Choose where to Add to: a project or the shared settings.
3. Answer What are you importing?: Protected requesters, Requester rules or Custom phrases.
4. Paste account IDs or phrases, one per line, or a CSV exported from this app.
5. Select Preview import, then Import [n] items once every line is ready.

Each line is marked Ready, Already added, Needs requester, Unsupported, Needs fixing or Protected. An account ID is checked for its format only (Valid format; account not verified in Jira.). Nothing imports until every line is ready. Email addresses and domains cannot be imported. Phrases are plain words, not regular expressions. Import up to 500 items or 200,000 characters at a time. Imported rules and phrases send matching requests to Review.

Download settings CSV saves the protected requesters, requester rules and custom phrases for your selection; choose Export from first if there is more than one source. You can import the file into another project or into the shared settings.

• Rule previews can check the last 60 days of requests, not just 14.
• History is kept for 180 days instead of 30. Reopen still works for eligible requests for up to 30 days after closing.

If a site moves from Advanced to Standard, saved protections still apply, and organisations stay protected. Shared settings stay saved but are no longer applied. Editing shared settings and the other Advanced features needs Advanced again.

• Check that Use AutoReply Guard is on for the project and that you selected Save changes.
• Only new requests created from email are checked. Replies that Jira adds as comments to an existing request are not.
• Check whether AutoReply Guard is paused. Requests received during a pause are not checked later.
• Requests you do not have permission to view are not shown, and the page tells you how many.
• If a warning says Requests haven't been checked for [time]., check the app's access and setup, then review requests received since the last successful check in Jira.

Read the lines under What should happen to automatic messages?. They name the missing checks and the requests still waiting in Review. Fix each one and wait for the initial email check to finish.

“Finish Closing requests in Jira first: select Check settings, then Close and reopen test request. When both pass, choose Close automatically again.” / “Finish Closing requests in Jira for this project in Settings.”

Complete Set up automatic closing: choose the Jira status, select Check settings, then close and reopen a test request.

“Save changes before running this check.” / “Save your changes before testing.”

Select Save changes first, then run the check or the test.

The test request is refused

Use a request from this project, created for testing, with “test” in its summary and still unresolved. Paste its Jira link or request ID.

“This project doesn't have a usable Closed transition yet.”

Ask a Jira administrator to add a way to close and reopen these requests, then select Check settings again.

“Automatic closing is on for [project], but waiting for setup for [request type]. Select Check settings.”

The daily recheck found a problem, often a workflow edit, or that request type has not been tested. Select View settings and test, then Check settings. Fix the failed check, or run the test request for that request type.

“Automatic closing is off in [project]. AutoReply Guard no longer has permission to change request statuses.”

Ask a Jira administrator to restore the app's Transition Issues permission, then select Check settings again.

Reopen is available for up to 30 days after closing, only for requests closed through AutoReply Guard, and only when the Jira workflow allows the change. In each case below, open the request in Jira to change its status there.

“The 30-day reopen window has ended.”

Open the request in Jira and change its status there.

“This request changed after it was closed, so we haven't reopened it.”

Someone or something changed it after closing. Check the latest details in Jira and reopen it there if needed.

“This workflow has no way to return from [status] to [status].”

Ask a Jira administrator to add that transition to the workflow.

“Jira didn't allow this request to reopen.”

Open it in Jira to see what is blocking the transition.

“Only requests closed by AutoReply Guard can be reopened here.”

This request was closed another way. Change its status in Jira.

Closing changes a request's status. Many queues and Unresolved filters look at the resolution instead, so a closed request with an empty resolution can still appear. Check your queue filters, consider a resolution for closed requests, and check that each SLA goal stops or pauses at the status you chose.

• Check the Project and Outcome filters, and the hidden ones under More filters. Clear filters resets them all.
• The dates filter by when the request arrived. If you see The start date must be on or before the end date., change Received from or Received until.
• Requests you do not have permission to view are not shown.
• History is kept for 30 days on Standard and 180 days on Advanced. Select Load more for older requests.

“No service projects are available to configure”

You need project administrator access to at least one service project.

“You need project administrator access to change these settings.”

Ask a Jira administrator to make you a project admin, or ask a project admin to make the change.

“Only Jira administrators can pause or resume processing.”

Ask a Jira administrator.

“We couldn't confirm whether the change was saved.” / “Someone changed these settings.”

Reload the latest settings and check them before trying again.

“This request can't be closed from its current status. Open it in Jira to check.”

The workflow has no route to your status for closed requests from where the request is now.

“We couldn't confirm whether [key] closed.”

Check the request in Jira before trying again. It shows as Needs attention in History until confirmed.

“This request has already been reviewed.” / “Another action is in progress for this request.”

A teammate got there first, or an action is still running. Refresh, or wait for it to finish.

“Your trial or subscription has ended.”

The app is not checking or closing requests, and settings cannot be changed. History and Reopen still work. Renew the subscription to resume.

To classify a request, the app reads its summary and description. It stores one decision record per request it handles in Forge storage, inside Atlassian. That record holds the outcome and the evidence shown in the details: the matched wording and, where one was recorded, a message excerpt.

It stores the Jira account IDs of protected requesters. For a teammate who kept, closed or reopened a request, it stores their account ID and can store their display name, which History shows as who acted. The app does not keep a separate email archive, but excerpts can contain personal information from the original request, and a short excerpt can include all the text of a short message.

In each project it needs the Jira permissions that Check settings names: browse the project, transition requests and add comments (the internal note). It acts only in projects where an admin has turned on Use AutoReply Guard, and only with the permissions granted in each project's permission scheme. The app is built on Atlassian Forge; all processing and storage stay inside Atlassian's infrastructure.

History records are removed after 30 days, or 180 days on Advanced. More detail is on the privacy page.

AutoReply Guard comes in two editions, Standard and Advanced, with no free edition. Either can be tried free for 30 days with Atlassian's standard evaluation. Pricing follows the user tier of your Jira site; there is no email-volume meter. Standard includes everything on this page except the Advanced features.

The 14-day and 60-day rule-preview windows are how far back a preview looks; they do not extend a free trial. If the trial or subscription ends, AutoReply Guard stops checking and closing requests, and settings cannot be changed. You can still view settings and History, reopen eligible requests, and pause or resume processing.

A Jira administrator uninstalls from Apps → Manage apps. Checking and closing stop, and the app's stored data is removed by Atlassian under Forge's app-removal rules. Requests the app already closed stay closed, and their internal notes stay in Jira. To put back recent closures, use Reopen in History on eligible requests before you uninstall; afterwards, change the status in Jira instead.