Prevent assigning a mismatched set of Reporter/Participants to Organization

[Patrick]

As a Service Desk Member (SDM), I can create a ticket in a Jira Service Desk (Desk) that contains external customers of multiple companies organized into Organizations.  Note, customers from one Organization SHOULD NOT view tickets from another.  To create a ticket I can do this in the following scenarios.  I make a distinction between the Web Portal and the Jira UI (the normal Jira user interface that actual licensed Service Desk Members can access).

Ticket Scenarios:

1) On Behalf of Customer (via Web Portal)

2) On Behalf a Customer (via Jira UI) - Sets the reporter at creation

3) Create a ticket, assign the Reporter and Organization later (via Jira UI) - allows us to draft a ticket and later assign to the Reporter/Organization so they can see it.

QUESTION:  In scenarios 2 and 3, how do I prevent a SDM from assigning the Reporter to a ticket for a Organization they are not a part of?  OR the other way, assign a Organization to a ticket when the Reporter is from a different Organization? 

Currently, only scenario 1 has built in Jira rules to prevent this from happening.  For scenarios 2 and 3, I can easily assign a ticket with a Reporter or Participants all from different Organizations that do not even match the Organization field set value.  There's no prevention and I see NO WAY TO ADD IT.

Am I missing something here?

By the way, I have permissions so a customer can only see their ticket and those of their Organization.  Also, I have to register new customer users so this is not an open Desk.

How is seems like Jira Service Desk should work or be configured to do

Jira should allow you to set a Reporter or Organization and then scope down the other field's possible values relative to what you selected. 

For example, if I select customer 1 as the ticket reporter from OrgA, then the Organization field should ONLY allow me to set it to OrgA.  If I also try to assign Participants to the ticket, then again, only the available Participants of OrgA should be available for assignment.

The Web Portal actually works this way when you create a ticket on be half of a customer (scenario 1 above).  When you do, the Share with Organization field is limited to only that Reporter's Organization.

This seems like an accident waiting to happen for SDM team resulting in a customer seeing information from the wrong Organization.

HELP?  

[Dan Breyen · Accepted solution]

Hi @Patrick Buchanan I believe the issue you are running into is JSDCLOUD-8306. I agree, JSM would be much more helpful if the Organization could be based on the Reporter, and the Reporters based on the Organization.  You have to be careful to make sure the right reporter is matched up with the Organization.  It's certainly an extra challenge for Agents. I would recommend you vote for and watch that ticket for updates.  I could possibly read that ticket slightly different than the way it's written to include the "limit the Organization to the reporter if they are a 'Customer'", and if you don't think that requirement is included in that ticket, you can make another on Atlassian's Jira Site, or contact Atlassian Support to see if there is something that I missed.

[Patrick]

Thank you.  FYI, that link doesn't seem to work for me.  Do you have the full link?

[Patrick]

Found the full link https://jira.atlassian.com/browse/JSDCLOUD-8306

Yes, that is essentially part of the problem.  This ticket was created in 2019 with no fix, so I assume Atlassian is not going to fix this.  I am just really surprised at this.

@Dan Breyen do you deal with this?

Are other people finding this is an issue or does everyone find this is just not a big deal?  

Is there any other fix to this or product without moving away from Jira?

Thanks in advance!

[Dan Breyen]

Yes, this is a challenge.  I can't let my customers from one company see Service Requests from another company, so I have to keep an eye on it and manually change it when I see it happen.  It would be a large timesaver if the software could control the lookups by organization.  If people can continue to comment on that ticket as well as vote for it, hopefully it will get looked at sooner than later.

I did make an automation (well, with much assistance from Support) where the Organization of the reporter will get filled in if there is only one Organization assigned to that customer.  That's also been a big help.  It involves a few API calls which is why I had support help.

[Patrick]

Thank you for responding.  I'd love to discuss that automation.  I see the options as the following:

1) 1:1 ratio desk to customer - (This is what I do currently with 9 customers/Organizations) This means create a desk for each customer and only add that customer Organization to the desk.  This will solve the issue but create maintenance issues.  Depends on how many customers you have really.  Jira doesn't seem to have any limit to the number of desks.  

2) Multi-Org Desk - Do the multi-org desk but including automation for:

    a) setting the Organizations field to the Reporter's Org when Reporter changes.

3) switch from Jira to another Product (Zendesk, etc.) for Customer service.  - Not sure if the same issues exist.

@Dan Breyen it sounds like you do Solution 2.  Questions:

Q1 - How many customer organizations are you dealing with?  I have 9 but growing which is why I wanted to move to Multi-org.

Q2 - Do you have any validation rules to warn you if a Organization and Reporter are mismatched?  If so, love if you would share.

Q3 - Any other gap like the reporter/Organizations mismatch that you see?  For example, it looks like you can assign a mismatched set of customer participants as well.  I don't see this as a big a risk, because internal Service Desk Members (SDM) should be trained NOT to set Client participants.  That should be left up to the Customer.  The Web Portal only allows the Customer to set other participants in their Org so it is fixed there.

[Dan Breyen]

I have 45 Organizations, so doing the 1-1 won't work.

I don't have any rules for the mismatching.  I was hoping to not have to go down that road.  

Yeah, certainly similar issue w/ Request Participants.  Our Agents need to be extra careful, we do see a use case for having Agents add Request Participants, but for now they need to be careful.  As we're transferring from a different process where more people were involved, it necessitates adding more people.