Organization Share Effects when editing tickets

[Viktor Karlsson]

Hi, I'm evaluating JSM and few other products as a potential new SD-tool.

One thing that I just can't wrap my head around is the organization sharing and its potential effects. Our scenario is mostly b2b were organizations would contain 5-10 reporters each, and they would then request support from us, and they (the different orgs) are defiantly not related and should not in any way risk seeing issues between each other. 

Two things:

* Why is organization sharing the only field that connects an issue to the organisation ? Sharing a ticket has nothing to do with if the ticket belongs to an org or not, plenty of other service-desks has this as a core feature. If you've tickets created by customer that is part of an organisation then logically you would have something on the issue binding the two. 

* Say that:

1. A customer of org. X creates an issue and shares it with their org X

2. Agent in backend switches reporter on the issue to someone in Org Y by mistake This causes a totally different org to have access to the ticket. Can I set restrictions or do I literally have to clear org in automation everytime something happens to ensure i dont get a complete mismatch because an agent might write a name wrong ? 

I like JIRA because if your willing to put down the time you can configure so much compared to other out of the box solutions, but damn, sometimes pure core functionality such as this and teams/groups/second line is just handled so differently.

[Josh Costella]

@Viktor Karlsson What @Jack Brickey said. However, I would take it a step further. 

I would look at why modifying the reporter would be something that needed to happen often enough to begin with that would warrant this concern?

Is there an overabundance of people creating tickets for other people and the service team has to correct it? 

If it was me, I would try to solve for that first since that seems like an uncommon process and use case. 

[Viktor Karlsson]

Thanks for the quick responses.

I agree that it's a handling error, but it's not a one in a million use case here. It happens that for one reason or the other we need to change the reporter. It could be someone quits on the opposite company, vacation or something that should've been assigned to someone else, or just something urgent and the person on the other end isnt working that day. This is b2b territory, and maybe I've the wrong expectations on jira for it ?

It's just extremely easy to do this mistake because you type a name in a list where many people could have the same name (because it's not scoped in any way), and this one mistake could obviously cause a lot of sensitive information leaking to a completely different company.

Safest route seems to be not to allow this field to change. Just wanted to ask in case I missed something.

[Jack Brickey]

So in JSM customers can optionally belong to an organization as a means of grouping customers. Customers in one organization cannot see issues associated with an organization they do not belong to. A reporter can optionally share an issue with their colleagues if the are in the same organization. By the way, they don't have to share an issue with the entire organization.

now, yes, if an agent was to change the reporter from a customer belonging to Org A to a customer in Org B then the wrong folks are going to potentially get updated on issues outside their Org. But in my mind that is a human error just like sending an email to the wrong person(s).

[Mark Segall]

To add to Jack's comment, if you don't trust the agents, you can always deny "Modify Reporter" permission in the permission scheme.