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?
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.
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:
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.
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.
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.
So here is a good example of our problem. We just yesterday had a customer raise a request through our portal. A member of our team immediately started emailing colleagues about how to handle the request, while CC'ing the mail handler. Team members replied to the email chain answering his questions and after a little back and forth they arrived at an answer -- great! The team member then responded directly to the client and the issue was resolved. This is how we envisioned using the product -- all conversations are captured so we can always see everything that happened relating to a given request. However, when we looked to the issue in JIRA we quickly discovered that ALL of the internal communications were VISIBLE TO THE CUSTOMER from their own portal view. That is a huge problem for us.
Therefore, if you or anyone else has any ideas about an approach others have followed to avoid this I would love to hear it.
So far some of my ideas include:
1) Use customer portal only as a triage center, where any requests involving any real internal interaction are spun off to a normal JIRA project, outside of service desk. This seems like a lot of footwork and my concern is that the additional process may result in steps not being followed correctly.
2) Never copy the mail handler on internal communications. The problem with this is that we're not tracking anything in JIRA anymore, which is the whole point of it to us.
3) Eliminate service desk & portal altogether and use a more traditional JIRA email support box system, where everything gets captured by JIRA and we can choose whether or not to include a client on any email.
At the end of the day I'm trying to find a workflow that uses service desk as intended so as to avoid surprises like this one. I feel as if we must be missing something fundamental about how best to use service desk.
@Jonathan Zschau Im glad you bring this up since we are having the exact same issue in our organization.
Why cant the Internal Comment just be made the default option for all comments?
At the moment the padlock on my comments is default to Viewable by all Users:
Im not sure why JIRA is not solving simple deal breakers like this. Confidentiality and Privacy are key concerns these days
Yes, we are having this issue too!
We solved most issues by using an add on called 'email this issue'
Hope this helps
Same problem here: there is this 3rd party "actor" ("delegated entity") which plays as 2nd tier support. Some issues are sent them asking for support. They will answer these requests and we want their answers to be tracked as internal comments, not visible to Customers.
I was able to get Internal Comments by configuring the Jira Mail Handler, but then realized it causes conflicts with Jira SD and its use is not recommended for Service Desk Projects ( https://confluence.atlassian.com/servicedeskcloud/receiving-requests-by-email-747602718.html ).
@Charlotte Webbe: we are using the same add on, which is great for outgoing email notifications; but didn't manage to have incoming emails tracked as Internal Comments (along with other problems, like adding CC addresses to Request participants)
Hey Community! I work at Atlassian in product marketing and we are conducting a survey to better understand how people feel about their development tool chain and DevOps. We would love if you could...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events