Service desk customer (custom user picker field) can't see issues assigned to them

Erki Jolla

I have a request type that is hidden from portal (no Portal group assigned) called "Analysis" and it is linked to the same named work type.

Agents create those work items, and assign someone to fill in a form or comment on the work item. 95% of the cases those users who get assigned are not licensed users, they are just SD customers.

To assign those work items I created a custom user picker field named "Responsible".

I have an automation that will send an email to person who is in "Responsible" field.

But when they click on the link in the email they see a error message that they don't have access to this issue.

I know the workaround or expected solution would be to add those people to Req. Participant field but I was thinking to reserve this for something else.

My question is - is there any other way I can bypass Jira default Assignee, Req participant or Creator fields with custom User pickers and achieve the similar result - issue being visible to the SD customer?

ashu patel_rub1iq

In Jira Service Management (JSM), only specific roles—such as Reporter, Request Participants, or Organization Members—have permission to view issues via the customer portal. A custom user picker field like "Responsible" doesn't automatically grant access.

Unfortunately, Jira does not allow access to be granted to customers just by being selected in a custom field, even if it contains a user.

Options you can consider:

1. Automation to add users in “Responsible” to Request Participants
   You can keep using the "Responsible" field, but create an automation rule that copies that user to the Request Participants field. This keeps your custom field intact while enabling portal access.

2. Add Responsible users to an Organization
   If the issue is linked to an Organization and the “Responsible” person is part of that org, they can view the issue—only if your project settings allow Organization sharing.

3. Give temporary agent licenses (not scalable)
   This isn’t practical or cost-effective, but assigning users as agents gives them full access—though they’d need a Jira license.