Hola Claude,
I dug into this a bit further, and there’s a native approach that can get you closer to what you want, although there’s one limitation you’ll have to decide whether you’re comfortable with.
JSM’s allowlist really does bypass the Auto-reply mail filter. Atlassian states that messages from an allowlisted domain are processed regardless of the Auto-Submitted header.
The catch is that the allowlist is domain-based. It can’t currently target an individual customer address, wildcard, or just OOO messages. So I wouldn’t simply allowlist every domain represented across 6,000 customers.
I think this becomes practical for customer domains where proactive outreach is common or important.
For those domains, I’d do two things:
- First, add the trusted customer domain under: Space settings > Channels & self service > Email > More > Manage allowlist
- Second, for the proactive outreach itself, I’d consider sending the initial message via Automation rather than relying solely on the standard customer notification. Atlassian supports configuring an Automation “Send email” action so that replies return to the JSM mail handler and are associated with the existing request.
The important bits are:
Subject: {{issue.key}} - your subject
Reply-To: your JSM service space email address
With the issue key in the subject and the service space email address as Reply-To, the customer’s normal reply, and an OOO reply that JSM is permitted to process, can be associated with the existing request rather than creating a separate one.
That gives you a fully native flow: Agent creates proactive request > Automation sends the customer email > OOO reply returns to the JSM email channel > allowlist prevents the Auto-reply filter from discarding it > JSM adds it as a comment on the request
You could take it one step further by adding another Automation rule that triggers when a comment is added. If the comment contains common OOO language such as “out of office,” “automatic reply,” “on leave,” or similar phrases, the rule could add a label such as customer-ooo, add an internal note, or move the request into an “Awaiting customer return” status.
If most proactive outreach goes to a manageable set of customer organizations, I’d only allowlist those trusted domains.
If proactive outreach is widespread and you really need OOO visibility across a very large number of domains, I’d consider putting that workflow in a dedicated JSM service space. You could be more permissive with its allowlist without weakening the inbound filtering on your normal support space. The proactive requests themselves would live there, so the replies and OOO comments would remain naturally threaded to the right work item.
What I wouldn’t do is turn off filtering globally or try to maintain a constantly changing allowlist through Automation. I couldn’t find a supported JSM Cloud REST endpoint for managing the email allowlist, so I wouldn’t build a solution that dynamically adds and removes domains.
If you test this with one trusted domain first, I think you’ll know pretty quickly whether it gives you the visibility you’re after without creating too much unwanted mail.
Thanks,
James
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.