Remove all visibility of Reporter from ticket

Question

I would like for a user to submit a ticket and then never have access or visibility to that ticket again. They will be directed to another ticket that acts as a dashboard for that ticket's process.

What's the best way to keep the original parent ticket reporter anonymous/uninvolved?

Thank you!

Sami Shaik · Answer

Hello @jennifer_doll , @James Gamble design is the right one (keep the Reporter for the audit trail, hide with issue security), so I will add the half nobody has covered: what the person who raised the request actually sees on the portal afterwards, and what breaks. This is all documented behaviour, so you can design against it rather than test blind.

The portal rule, inverted. Atlassian's troubleshooting KB states that for a customer to see a request on the portal, the security level must include Reporter and the Service Space Customer - Portal Access role (Understand common issues in JSM Cloud). Build a level that includes neither (say "Internal only," members: the Service Desk Team role and Administrators), apply it to the request, and the reporter gets "No Access" on the portal, including from a direct link (request not visible due to a security level). That is the invisibility you asked for, with the Reporter field untouched.

The redirect. In the same automation rule that sets the level on creation, create the tracking ticket with the original person as its Reporter and no security level, and link the two. Their portal then shows exactly one request, the tracking one. If you want them to be able to reach it from the confirmation email, put the tracking key in the customer notification of the tracking ticket, not the original.

Two consequences to decide on, not discover:

* Notifications. Once a security level excludes the customer, the original request stops being something Jira will notify them about; that is the whole point, but it also means any customer notification you relied on from the original request has to come from the tracking ticket instead. Atlassian's KB on security levels and participants describes the same effect and the automation workaround (issue security for request participants).
* Participants and organisation sharing are cut off by the level too. If the original request is ever shared with an organisation or given participants, they will see No Access as well, because Request participants cannot be added to a security level (that is the open suggestion JSDCLOUD-1703). Keep collaboration on the tracking ticket.

One boundary: agents are not hidden by this. A licensed agent who is also the reporter can still see the request through the agent view, so if your reporters are sometimes internal staff with agent licences, the design only hides it from the portal, not from Jira itself. Aaron's rewrite-the-Reporter route is the only way to hide it from an agent, at the cost of the audit trail James rightly wants to keep.

Rilwan Ahmed · Answer

Hi @jennifer_doll ,

I also suggest Issue security as suggested by @James Gamble

James Gamble · Answer

Hola Jennifer,

@Brandon Viertel's suggestion is the direction I'd take here. I'd avoid changing the Reporter to Automation unless you specifically need to anonymize the request's internal submitter, because changing Reporter also changes the request's ownership and can affect customer notifications, portal behavior, and reporting.

For what you described, work item security is a cleaner fit: let the customer submit the request normally, preserve them as Reporter for your internal audit trail, but apply a security level that doesn't grant access to Reporter or Service Space Customer - Portal Access.

Atlassian specifically notes that a JSM request with a security level must include Reporter and Service Space Customer - Portal Access for the customer to continue seeing it in the portal. In your case, you'd intentionally do the opposite.

Since you're on Premium, you can configure this under:

Space settings > Access > Issue security

I'd create a security level that includes only the agent roles/groups that should be able to work the original request, and exclude Reporter and Service Space Customer - Portal Access.

Then either set that as the default security level for these requests, or use Automation to apply it immediately after creation if only certain request types should behave this way.

One important note: this hides the request from the Reporter, but it doesn't make the Reporter anonymous to the agents who are allowed to see the request. They'll still be able to see who submitted it. If you actually need the submitter's identity hidden from the people processing the request as well, that's a different requirement, and I'd design that separately rather than simply changing Reporter.

I'd also test the full customer experience with a non-agent account before rolling it out: submit the request, verify the original disappears from Requests > Created by me, confirm its direct portal URL is denied, and make sure the separate "dashboard" request you're directing them to still exposes only the information you intend.

Thanks,

James