Hello @Chris Adams , direct answer first: no, there is no allowlist. Safe customer notifications is a site-wide compliance setting (Settings, then Apps, then Compliance settings under Jira Service Management) and it masks summary, description, comment and attachment content in every customer notification the site sends; it has no recipient, domain or project dimension (About safe customer notifications). So the question becomes how to get full-detail emails to your internal people without turning it off, and that is possible, because of a distinction the setting relies on.
It only masks customer notifications, not internal ones. JSM sends two different email streams: customer notifications (the templates under Space settings, Notifications, Customer notifications, which is what the compliance setting masks) and internal notifications, which come from the space's Jira notification scheme and are never touched by it (what notifications customers and team receive). Your agents are getting stripped emails because they are receiving the customer stream, which happens whenever an agent sits in the Reporter, Request participant or Approver field, or is in an organisation the request is shared with.
The exemption is by role, not by address. Atlassian's troubleshooting KB states it plainly: a person added as watcher or assignee receives internal notifications instead of customer notifications (fix customer notification issues). So the design is:
- Stop putting internal staff in customer-role fields (participant, approver) when the goal is to keep them informed; use watchers, the assignee, or a role in the notification scheme (for example a "Service desk team" role receiving Work item commented) instead.
- Make sure the notification scheme actually includes the events your agents rely on (commented, updated, transitioned); internal notifications carry the full comment body and summary.
- If some internal people must stay approvers or participants (a real approver has to be in the Approver field), accept that those specific emails are masked and give them the portal link; that is the trade the compliance setting exists to make.
Two boundaries to know: the masked variables in customer templates render as bullets and cannot be edited around; and emails sent by automation rules are not customer notifications, so they are not masked, which is a route for a deliberate internal digest, and also the reason Atlassian's HIPAA guidance tells you to review any rule that emails work item content when the setting is on.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.