nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA Service Desk Email Handler & Comments

Jonathan Zschau

Hello:

We just started using service desk & a customer portal and I've run into an potential problem involving emailed communications and service desk issues. The scenario is as follows: a client creates issue in the customer portal and then we need to send internal emails back and forth between our own internal team and external partners while capturing those conversations in the JIRA issue, but we do not want all of this internal chatter to be visible to the client via their portal view. Is there a way we can use email as our primary mode of communication without also including the client on these conversations? Thanks in advance.

I suppose the simplest solution would be to make any comments received via email (if made by an Agent) to be defaulted to internal instead of visible to the client. Is that possible?

Accepted answers

All comments

Brant Schroeder

The only way to prevent the customer from seeing the communications in the portal is to have them as internal comments. If a user is setup on a service desk with a standard JIRA license and not an agent license and they have been given permission to the service desk their replies will be internal. They would however have access to see all of the issues in a JIRA service desk. You could use issue security to prevent that but it would not be fun maintaining. You could also manually create a linked issue or use a plugin to link it with another issue where those conversations take place.

Is there a reason you do not want the customer seeing the conversations other than email chatter? If it is only email chatter you might look at adjusting the notifications that JIRA sends out.

Jonathan Zschau

Thank you for the quick reply, Brant. We work with other 3rd party vendors on client requests and also discuss the client requests internally as a team. We need to capture these exchanges for auditing & reference purposes (E&O requirements / plus we want to be able to research the history of issues if someone is not available to help, which is an invaluable aspect of JIRA I've always loved), but obviously we cannot have our clients reading everything email exchange while we work through their problems. I've already turned off notifications, but that doesn't prevent them from still being able to see everything if they were to log into the portal. Cutting portal access and simply doing it the old JIRA (i.e. a support email address, creating issues manually, etc.) but then we don't get to have the nice customer portal.

My initial thought was to limit the number of Service Desk Agents such that we only have one or two accounts acting as the portal servicers, and keeping everyone else a normal JIRA user and, therefore, any email exchanges involving the JIRA-only users would still get updated to the issues as INTERNAL comments, but then the non-service desk agents aren't able to actually work on any of the service desk issues -- so no assigning issues to team members, working on issues, etc. because you need to be a SD agent to do so. We'd be happy to pay for the agents, but they're of no use if everything an agent says (via email) will always be entirely visible to any client that chooses to log in and view their issues.

If you have any ideas about how to accomplish what we're trying to do I'd love to hear.

PS, this is talking about exactly our problem:

https://community.atlassian.com/t5/Jira-Service-Desk-questions/JIRA-Service-Desk-Can-an-external-third-party-be-involved-via/qaq-p/613105

It doesn’t appear as if they solved it themselves here, but it sounds they people all have a similar need to us. We deal with dozens of different companies and probably hundreds of third party contacts so adding them as licensed JIRA users isn’t an option for us.

By far the simplest solution would just be a option to have any communication updated to the issue via the mail handler be defaulted to be an internal comment, hidden from the client so that the conversation with third party vendors and internal contacts can carry on without disclosing information to the client...

I’m struggling to find a solution that uses Service Desk. If using service desk we must use Agents if we are to work on, assign, etc. any issues. But it seems Agents cannot send emails to third parties — while CCing a JIRA mail handler so as to update the issue with the internal discussions — without disclosing that confidential content of these emails to the client.

Brant Schroeder

We setup a service desk where the agents were tier one support and had total ownership. The tier two and tier three support were JIRA users and could work the issue. The assignment stayed with the agent and we used a custom field called Escalation Assignee to assign the issue to tier two or tier three support. A dashboard was created for tier two and tier three support so they could see issues assigned to them based on the custom field. The only issue was the custom field allowed for anyone to be selected occasional someone would accidentally select someone who was not tier two or three but this was usually caught by the agent as they monitored the issue. Hope this helps.

Jonathan Zschau

Thanks again for your response Brant. The lack of ability to control internal only vs. client-facing communications is a total dealbreaker for us. There are many situations where sharing every detail with our clients would run afoul with industry regulations and, therefore, we need to be able to use our professional judgement regarding what is shared with the client and what is not, but we also need to make sure all communications relating to an issue is tracked for auditing purposes at our business level.

While it’s really, really nice to have a customer portal linked to a Confluence knowledge base, it seems that Service Desk (SD) is totally inflexible on the ability to collaborate with external parties. A reasonable solution may be to EITHER let non-SD Agents work on issues (because their comments aren’t shared with the client and, therefore, they could work on issues and collaborate with external parties automatically); OR, let SD Agents have some control over what gets shared with the client (ie emails pulled in by a mail handler are, by default, internal). As it stands, at least it seems, there is no way to control whether or not a simple email (CCing a mail handler, so we can update the issue and record the conversation), is shared with a client Reporter on a service desk issue.

I’m really hoping to figure out something that will work for us, but it seems as if the only way to do this is to cancel our SD subscription and replace our portal with regular JIRA instance and just advise clients to email requests in to our service email address (in lieu of using a customer portal).

The bottom line is we need to be able to have, and track, internal conversations without including the client. This is very easy to do with regular JIRA software, why is this not the case with the more refined JiRA Service Desk, which was marketed to us as being designed for business circumstances just like ours. Obviously, if I’m missing something here I’d love to hear from anyone more knowledgeable than myself.

Thanks again.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-desk

jira-service-desk-cloud

jira-cloud