Can you restrict tickets that customers see in the portal?

@Bree Polk-Bauman ,

@Matthew Sinclair has the visibility model right, and it is the reason there is no setting for what you want: a customer sees a request on the portal when they are its reporter, a request participant, or a member of an organization it is shared with. Your migration is writing the real users into the reporter field of the old tickets, so JSM is doing exactly what it is designed to do: showing people their own history. The fix is to change what the import writes, or where it writes it.

Option 1, the clean one: land the history somewhere the portal does not show. Import the legacy tickets into a separate archive project, not the live service project. Two shapes work:

• A Jira business (work management) project has no customer portal at all, so nothing in it is ever visible to portal customers, while agents keep full search, JQL and links to the old records.
• If you need it to stay a service project (for SLAs or request-type reporting on old data), keep it as a service project that is not published in the Help Center and give it a customer permission of "customers added by agents and admins" with nobody added; a request is only visible through a portal the customer can reach.

Agents lose nothing; customers never see the archive; and the live project starts with a clean "Requests" list for every user.

Option 2, if the tickets must be in the live project: change the reporter after import. Create a service account customer (for example "Legacy Migration") and set it as reporter on every imported ticket, which removes them from the real users' portal lists in the same moment. Do it in this order so you do not lose attribution:

1. Before the bulk change, run an automation or bulk edit that copies the current reporter into a text field ("Original requester"), so the history stays searchable.
2. Bulk change → Edit → Reporter on a JQL such as project = X AND created < "2026-09-01" (or whatever marks the import).
3. Check Request participants and organization sharing on a sample of the imported tickets; if the importer populated either, clear those too, since each is an independent path to visibility.

What does not work: removing the request type to make tickets "invisible" is sometimes suggested; it does hide them from the portal, but it also strips them out of request-type reporting and makes them fail on every automation that expects one. Treat it as a last resort, not a plan.

If your migration tool lets you map the source requester to a fixed account (most do, even when they default to email matching), Option 2's step 2 happens for free during the import; that is the question to put to whoever runs the tool before the production cut-over.

Jira Service Management (JSM) - assuming default configuration in customer settings (may not be the right term) - should do that out of the box.

So short answer - you should be ok.

-------
Details:

Basically any ticket submitted can only be viewed by the following:

The Space Admin's/Agents - whom have a JSM license (Agent) - and Space Access/Role assigned. - You can compare these to regular Jira users - Just JSM context.

The Collaborators - Space Access - and a Jira Seat (although there may be more granularity - and may have changed recently) - these can see "Agent" view and only comment.

The Requestor/Reporter - the "Customer" who submitted the ticket. (Customer Seat - Free) - This can be changed from user to user - if you remove the user and move it - it removes access unless they are a participant (see next item)

The "Request Participants" - these are users "invited" to be able to view the ticket and collaborate in the discussion - who do not need a JSM Seat or a Space Access (usually). (Customer Seat - Free)

Depending on your Org configuration - an email address alone (Non Atlassian account) is an implied "Customer" - something to check on.

If you don't fit in the 4 above "boxes" - you can't see the ticket what-so-ever.

Also note that when you link a ticket - they can't even see it unless its a "Generic" url (like the portal) - things like queues in context or filters won't load - due to the permissions I detailed above. If you linked a different customers ticket - its "Access Denied" even then unless you are an Agent/Collaborator. It gets a little confusing at first when your new to JSM when linking tickets for Customers to review (Internal Support). As you would expect any kind of Customer Facing support system.

Example:

Customer A can see ABC-123 as they submitted it.
Customer B can see ABC-231 as they submitted it.
Customer A can't read ABC-231
Customer B can't read ABC-123
Customer A and B can't read any other tickets.
Customer C can't see anything - even if you link them ABC-123 and 231. "Access Denied"
Customer D is a Request Participant on ABC-123 and 231 - they can see them.
Customer E was "set" as Requestor/Reporter of ABC-123 - Customer A loses access - Customer E gets access.

Any links to the Agent view is not reachable by any Customer unless they have a Space Access with JSM Seat/Jira Seat (Collaborator).

Hopefully this makes sense as I may have jumbled terms.

If you have a sandbox instance you can test this yourself - just need a generic non-admin account to play guinea pig.

This also applies to CSM - presumably.

Sorry if this is a little muddy. Long day at work. :D