Customers Receive 403 Error When Opening Email Attachments
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
Customers may encounter error 403 (forbidden) when accessing an attachment from an email notification. The notification is likely sent via automation, and the user does not have internal access to view the attachment using the link.
Diagnosis
Why this happens
The attachment link in the email comes from the {{attachment.content}} automation smart value, which points to the internal REST URL. That URL is only accessible to licensed users — JSM portal customers usually have no product license, so they get a 403 error. The fix is to send customers the portal attachment URL instead.
When attempting to open an attachment link, one of the two errors appears:
User authenticated: Encountered a "403 - Forbidden" error while loading this page.
User not authenticated: {"errorMessages":["You do not have permission to view attachment with id: XXXXX"],"errors":{}}
Cause
The attachment link comes from an automation smart value
The link is generated using the Jira Automation {{attachment}} smart value. This allows agents to access some file attributes, like an attachment's name, URL, size, type, and author.
Although the smart value has an attribute containing the file URL ({{attachment.content}}), which allows it to be used as a link to send in an email notification, opening this link does not always work as expected.
The smart value link can only be accessed by licensed users, and in most cases, Jira Service Management customers don't have a product license. Hence, they can't open the attachment link.
Solution
Different attachment URLs
Let's compare the URL provided by the smart value against a proper URL where customers can download the attachments:
URL type | Pattern | Works for customers? |
|---|---|---|
Smart-value (internal) | /rest/api/2/attachment/content/<id> | ❌ Licensed users only → 403 |
Portal (customer) | /servicedesk/customershim/secure/attachment/<id>/<name>?fromIssue=<issue_id> | ✔️ Portal customers |
Note that the smart value URL has attributes that store everything we need to create the same structure as the customer attachment URL, allowing us to do the following:
Add attachments as a comment in requests
Go to Project settings > Automation > Create rule.
Configure a rule where:
Select the desired trigger.
Add an Action: Comment on work item. Add the following smart value to it:
{{#attachment}} !{{filename}}! {{/}}
Create a variable (example: {{requestattach}}) with the following structure:
<ul> {{#issue.attachment}} <li> <a href="{{content.replaceAll("(.*)(rest\/api\/2\/.*\/)(\d{5,})","$1servicedesk/customershim/secure/attachment/$3/")}}{{filename}}?fromIssue=replaceme">{{filename}}</a> </li> {{/issue.attachment}} </ul>Create another variable (example: {{issueId}}) with the following structure:
{{issue.id}}Now, on the Send Email action, call the variable with the following function to replace the replacement text with the second variable issueId:
{{requestattach.replace("replaceme",issueId)}}
Variable names in this rule (for example {{requestattach}}, {{issueId}}) are case-sensitive. If the email renders without working links, confirm the variable names match exactly across the Create-variable actions and the Send-email action.
Verification + prerequisites checklist
The customer is authenticated in the Portal.
The customer can see the request (they are the Reporter, a Request Participant, or a member of an Organization the request was shared with).
The comment carrying the attachment link is set to "Shared with Customer" visibility in the automation rule.
Verify: open the portal as the affected customer and confirm the attachment link now downloads instead of returning 403.
Was this helpful?