Table of Contents
In the dynamic environment of Jira Service Management (JSM), where teams collaborate seamlessly to address customer needs, there’s a peculiarity in how the default behavior of the Organizations field operates, often going unnoticed. This seemingly safe field has implications that extend far beyond its apparent functionality, potentially posing privacy risks and compromising the accuracy of reports per organization within JSM.
Why Doesn’t the Organizations Field Populate Automatically for Every Customer Request?
In Jira Service Management (JSM), the organizations field is vital for organizing and managing customer requests. However, there are cases where the organizations field doesn’t populate automatically for future requests from the same customer, particularly when the requests are raised through the customer portal without the customer logging in, accepting their invitations, or when their email domain doesn’t match the organization’s domain.
In such cases, the system may not automatically associate the request with the customer’s organization, even if the agent has manually added them to it in the Settings beforehand.
This limitation may lead agents to manually add the organization to the request itself.
Understanding the Default Behavior
Many JSM users may not be aware that when agents manually add organizations directly into the empty field within a customer’s request, they inadvertently share the request with the entire associated organization. The default configuration of the Organizations field allows for multiple selections, enabling agents to share requests not only within the requester’s organization but potentially across others as well. In simpler terms, if your Organizations field is filled out, then this request becomes visible to the entire organization it’s associated with.
It’s likely that every customer from this organization receives a notification about it.
Unveiling the Security Risks
The implications of this default behavior are profound. Requests that are shared with entire organizations may expose sensitive information to a wider audience than intended. What was once a private interaction between a customer and support agent becomes visible to a broader spectrum of individuals within an organization, raising concerns about data privacy and confidentiality.
Imagine a scenario where a support ticket contains proprietary or confidential information meant for the eyes of a select few. With the default Organizations field behavior, such information becomes accessible to every member within the associated organization, inadvertently increasing the risk of data breaches and internal leaks.
Challenges in Organizational Reporting: If Not Shared, It’s Not Included in the Report
Moreover, the default behavior of the Organizations field complicates organizational reporting within JSM. While many teams seek insights into ticket volumes and trends across different organizations they support, relying on the native or even third-party apps’ reporting capabilities becomes unreliable. Given the default behavior of the field, when generating reports per organization in Jira, only shared requests are included in your report.
Requests that were not shared are considered ’empty’ because their organizations field is not populated.
Conclusion
The default behavior of the Organizations field in Jira Service Management may seem innocuous at first glance, but upon closer inspection, reveals hidden risks and challenges that demand attention. From inadvertent data sharing to compromised organizational reporting, the implications of this default feature extend far beyond its surface functionality.
Check out our article about Reporting on Organizations Field in Jira where we explore further how custom fields, automation, and the Performance Objectives app can assist teams in navigating towards a future where insights foster informed decision-making without compromising privacy or security.
Start your 30 days free trial of Performance Objectives: Charts for Jira from Atlassian Marketplace.
