How to set organization on a issue without sharing the issue with the organization
Asked by Ivan Bilobrk:

Hi Community,

I'm facing a challenge with Jira Service Management regarding how organizations are handled. We need to assign an organization to each issue for analytics purposes and easier searching. However, we also want to respect the customer's choice not to share their issue with the rest of their organization.

Here's the problem:

* If a customer doesn't want to share the issue with their organization, they select "No one" in the "Share with" field when creating the issue via the request form on the customer portal.
* However, as I have concluded so far, if an agent later adds the organization (for internal tracking), the issue is automatically shared with the entire organization, which is not what the customer intended.

Our requirement is to keep the organization linked to the issue for internal purposes without forcing the issue to be shared with the entire organization if the customer opts for privacy.

Is there a way to achieve this without using a custom field for organizations? For example, can we assign the organization but restrict visibility using security levels or another approach?

Any help or best practices would be greatly appreciated!


Answers:
author: Joseph Chung Yin
body: [@Ivan Bilobrk](/t5/user/viewprofilepage/user-id/4941573) -

Give this a try:

1) If you want to control it at the Global level, meaning for all the JSM projects - then you can go to Settings \>\> Products \>\> Under the JSM section go to Configuration - Set "No" for

##### Should new requests automatically be shared with a customer's organization? {#toc-hId--1423281560}

2) If you want to control it at the specific project level, then you should be able to create issue security configuration setup with only project admins/service desk team role members and "Reporter" can see the issues. This security level will then needed to be assigned to the issues for the control to be enforced. This means that only the person who is the reporter of his/her issues + project admins and service desk team members can discover the issues. On the other hand, you can create a custom field (i.e. dropdown list data type) where you have to maintain the options that associate with the organization(s). Use this field for your internal tracking needs.

Hope this helps.

Best, Joseph Chung Yin

comments: author: Ivan Bilobrk
body: [@Joseph Chung Yin](/t5/user/viewprofilepage/user-id/396739)

Thank you for the suggestions!

Regarding the first solution, it doesn't fully solve the issue. The global setting that controls whether new requests are automatically shared only applies at creation. Our challenge arises when agents manually add the organization later for internal purposes, which still shares the issue with the entire organization, contrary to the customer's wishes.

As for the second suggestion involving Issue Security Levels, that seems like a valid approach, and I'll definitely consider it.

We would like to avoid using custom fields if possible.

Thanks again fory our help!


author: Joseph Chung Yin
body: [@Ivan Bilobrk](/t5/user/viewprofilepage/user-id/4941573) -

If my suggestions helped you, please click on Accept answer when you have a chance, so others with similar asks will see this posting as an answered one.

Best, Joseph


author: Ivan Bilobrk
body: [@Joseph Chung Yin](/t5/user/viewprofilepage/user-id/396739)

I greatly appreciate your suggestions, but unfortunately they do not solve the problem.


author: Ivan Bilobrk
body: **Hi Community,**

I previously posted about the challenge we're facing in Jira Service Management regarding how organizations are handled when customers choose not to share their issue with the rest of their organization. To recap:

We need to assign an organization to each issue for internal tracking, analytics, and proper support workflows. However, some customers, when submitting an issue through the portal, choose **"No one"** in the **"Share with"** field to keep their issue private from the rest of their organization. The problem arises when an agent later assigns the organization to the issue for internal purposes---this action automatically shares the issue with the entire organization, which conflicts with the customer's intent.

Since my last post, I've gathered some additional context:

1. **All issues must have an organization assigned** because our support processes are centered around knowing which organization the issue relates to. Agents need this context to handle issues effectively.

2. **Customers sometimes submit sensitive information** that must remain confidential, meaning no one else from their organization should see the issue. This creates a challenge when trying to balance internal organization tracking with customer privacy.

I've tried to address this using **Issue Security Levels**, but the issue persists. Even when the issue isn't visible to others due to security levels, the customer still sees that their issue is marked as "shared with the organization," which creates confusion since it technically isn't visible to anyone but the reporter and agents.

I find it surprising that there doesn't seem to be a clean way to resolve this. Has anyone faced similar challenges or implemented a workaround that addresses both organization visibility and customer privacy?

Any insights or best practices would be greatly appreciated!


Tags: cloud

customer-portal

jira-service-management

jira-service-management-cloud

organization

portal