How to set organization on a issue without sharing the issue with the organization

[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!

[Walter Buggenhout · Accepted solution]

Hi @Ivan Bilobrk,

It seems your question is still out in the open, looking at your last post of Sept, 25th:

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!

I noticed you mentioned that you stated the following earlier as well:

We would like to avoid using custom fields if possible.

However, looking at your use case, I am afraid the answer to your challenge is situated right there. The Organisations concept is designed explicitly to share tickets with customers belonging to the same company / team / group. If you want to do reporting on it as well, it is obviously quite practical that you can do this using the same field / concept.

The problem arises when your reporting requirements suddenly enforce the need to set the customer on each ticket, while you don't want that to make tickets shared with other members of the same organisation - while you still want to allow people to share tickets with their organisation (which makes perfect sense from a backup scenario).

If you want to keep all these options open, the obvious option is to not use the organisations field for reporting (as it makes the ticket visible by design), but set e.g. a customer field alongside this for reporting purposes.

We quite commonly use assets in the premium plan for scenarios like this, which offers a lot of additional benefits, as you can store a lot of additional information about your customer there, such as SLA agreements, products they own, contacts they have, etc.

Hope this helps!

[Ivan Bilobrk]

Hi @Walter Buggenhout 

Thank you for your response! You're absolutely right. After getting confirmation from Atlassian Support, they explained that the Organizations field is specifically designed for ticket sharing. Based on that, I’ve already implemented the solution you suggested by using a custom field for internal tracking.

The field description in the settings simply says: "Stores the organizations that are associated with a Service Desk customer portal requests". It would have been nice if Atlassian had provided a clearer explanation. Judging by the number of related questions on the Community, many users have misinterpreted its purpose.

Thanks again for your help!

[Joseph Chung Yin]

@Ivan Bilobrk -

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? 

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

[Ivan Bilobrk]

@Joseph Chung Yin 

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!

[Joseph Chung Yin]

@Ivan Bilobrk -

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

[Ivan Bilobrk]

@Joseph Chung Yin 

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

[Ivan Bilobrk]

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!

[Goran Plavsic]

Hi together

1. We need to be able to assign a request to a specific organization so that we can conduct various analyses.
2. This request should not be automatically shared with the entire organization, as it may contain sensitive information.
3. Ideally, we would like to grant permissions to, for example, the IT Manager of the organization, allowing them to view all requests related to their company.

If we could address the first two points, that would already be very helpful. The third point would be beneficial but isn’t a current priority.
So far, I haven’t found an effective way to implement this. I’d greatly appreciate any practical ideas or suggestions.

Thank you!

[Ivan Bilobrk]

Hi @Goran Plavsic 

Here's an overview of the solution I implemented:

1. I created a custom field, Organization, with a type of Select List (single choice). We use this field for internal analysis, filtering, etc., to indicate the organization to which the issue is addressed.
   
   
2. Using External Data for Jira Fields, I added a sync that populates this custom Organization field with Jira Organizations as selectable values.
   
   
3. I removed the default Organizations field from all Issue Views and replaced it with the custom Organization field. By moving the Organizations field in Jira, we prevent issues from being unintentionally shared with organizations. This change still allows the reporter to share the issue with their organization through the portal if desired.
   
   
4. I added an automation rule that sets the reporter’s organization in the custom Organization field when creating or editing an issue, provided the reporter is a customer. You can find an example here.

I hope this helps!

Ivan

[jd_santos]

Thanks @Ivan Bilobrk, both for sharing the problem and your workaround solution.

It's extremely frustrating that the tool for associating a customer with their parent organization also requires them sharing their ticket with everyone in that org. This isn't isn't an unusual requirement for managing a service desk, and I'm glad to see someone else point this out.

The real insult to injury is not having a first-party way to populate a separate customer field from Organizations, since we already have the email domain logic established there. "Just use a custom field" doesn't account for needing some way to automatically associate every single ticket with a specific customer, and the only tool for that is given to "Organizations." 

I'll move forward with your workaround for the time being, pending approval for yet another plugin that is required to backfill problems created by poor design decisions. 

JD