What does "comment internally" actually mean in JIRA Service Desk?

[Ji]

In JIRA Service Desk projects, comments are segregated by internal vs external visibility. Meaning that I am able to select whether I want to Share with customer or Comment Internally.

Which users are able to see comments that are specifically marked as internal?

I couldn't find proper documentation describing this feature.

[Nic Brough -Adaptavist-]

Share with customer makes the comment visible to everyone who can see the issue/request.

Internal comments do not appear on the requests, so a customer can not see them.

[Deleted user]

Internal comments are not shown on the portal view of the issue. However, everyone who can see the internal version of the JIRA ticket can see both internal and external comments!

Internal = "Everyone who uses JIRA and has access to this issue in JIRA itself. But not displayed on the portal view"

[Linda Wanitschek]

Thank you William.  Very clean statement.

[Michael Aniskovich]

I still remain confused by this.  "But not displayed on the portal view".

So, I respond to the submitter by tagging them (using the [~nnnnn] tag.

1.) Will they see it if I choose "Comment Internally"?

2.) What parameters constitute "Customer"?  (My assumption is that it's someone outside of my company, but I could be wrong.)

I would LOVE to see "hover-over" notes added to these kinds of things.  Kind of annoyed.

[Linda Wanitschek]

If a user chooses "Raise a Request"  on the customer portal view, there are comments displayed there.

The comments displayed on the Customer Portal View are only the comments where "Customer" is selected.

When Internal is selected the comments are displayed on the Issue view.

Customer is a person who is a reporter or any other person who can see the issue only thru the Customer Portal.

[Deleted user]

Edit: in addition to what Linda said (which was all correct).

Service Desk has an *additional* representation for Issues, called Portal view.

Internal comments are never displayed in the portal view. However they are displayed in the traditional issue view for everyone who has access to it, i.e. browse permission in your project. 

To restrict customers, who also happen to have access to your JIRA internally, you need to remove those people, as well as the Reporter from the "Browse Project" permission, and replace it with "Service desk customer - portal access".
Then it is ensured that customers can no longer see internal comments. However since they can't see internal tickets anymore, they can also not link them or do anything else with them. [~username] notifications only work if you have access to an internal ticket as well. Servicedesk automatically sends its own notifications, which are seperate from your JIRA notifications.

Sorry if I can't explain it any clearer, in my opinion the way Atlassian set this up is a complete joke and lazy design.

[YEW JOON KHONG]

can customer view internal comments as well? certain projects we would like the customer to view the internal comments from the developers , (developer can't post public comment as for now)

[Linda Wanitschek]

Yew,   no no no.

Internal is private internal only.  If you need a customer to be able to see internal, add them as a User in your roles. 

At Intel, we use this separation of Customer from Internal heavily. We would never vote for such a change. 

[Nic Brough -Adaptavist-]

I'm with Linda on this one - the whole point of the internal comment is that customers do not see them.

[Jon Starbird]

While I agree you should also have the option of a Collaborator comment being made visible to the Portal view. Not having that option at all makes Service Desk rather useless for companies who only use the tool internally. 

In our case for example, our Service Desk customers are our employees but we want a majority of them to only use the Portal view as they do not need regular access to Jira itself. For some issues our developers need to collaborate on the issue and they work primarily from Jira. 

It really defeats the purpose of Service Desk if you have to allow users to view issues in Jira if they are only Customers of the Service Desk. You might as well just not use Service Desk at that point.

[Linda Wanitschek]

we have automated emails that send the person a confirmation

and in the email are 3 hyperlinks to Issue queries.  And they default to the Detail view.

In this view, they do not see internal comments, but can see the entire request.  It's pretty easy to do this.

My Owned - Open:   

[Jon Starbird]

sure but again it takes them into Jira itself. So why use Service Desk then?

They then end up using two different interfaces to see their issues, why? Just give the option to have collaborator comments be visible to the portal view. 

I'm not saying make it default, I'm saying make it Service Desk Project setting option. There is no reason to not have the option. 

[YEW JOON KHONG]

Thanks for all the feedback , 

We don't operate service desk 24x7, but when there is a reported issue after hours, the on-call support/developer who is not part of SD may need to update the ticket and share with the customer. 

Basically, collaborators should have the option to post the comment internally or public.

[Linda Wanitschek]

We are experimenting with a form style that as long as the issue is in x status, the reporter can edit the issue.  Once the issue transitions to another workflow status, the reporter is not allowed to edit.  Unfortunately, the test is not going as happily as we would like.  

[Tim Jedlicka]

Atlassian already has a feature in JIRA that could address these issues and offer flexibility. In non-JSM JIRA (standard JIRA), one can specify who can view a comment based on JIRA roles or groups. It should be trivial to restore this feature to JSM-JIRA. 

[Nic Brough -Adaptavist-]

That function is significantly less old than this question is.  It's also counter-productive - it's an anti-collaboration pattern, and something that should be rarely, if ever, used.

Also, the usage of comments in JSM projects is for a different purpose, and this function would be of even less use in JSM.

[Tim Jedlicka]

It causes problems in our use case - our "customers" are all "internal developers" who use JSW. We support the developers using JSM. There are times when the support team needs to discuss an issue without involving the "customer or user". Since all our developers use JIRA (JSW), they now have access to our "internal" conversations. In our case it actually blocks collaboration within the internal team. Since switching from a JSW project to a JSM project we now have to take all internal conversation/collaboration outside of our ticketing system.

If comments aren't intended to be used this way in JSM, is there a way for the Service Desk team to collaborate within JSM? I tried worklog updates but that is also exposed to the customer. (Perhaps this should be a new question).

The functionality is there - just not the philosophy or understanding the use case where the "customers" of a help desk (JSM) are all "internal" developers (JSW). It would be nice if JSW and JSM could co-exist. 

[Nic Brough -Adaptavist-]

>In our case it actually blocks collaboration within the internal team

How does sharing information block collaboration?

> is there a way for the Service Desk team to collaborate within JSM?

That's what all service-management software does - share information across a team so they can work together.  I'm not sure what else you might be looking for.

Edit:  Sorry, I posted that and re-read it, and realised it was not clear on what is running through my mind - you have Agents, Developers and Customers. 

It's understandable why Customers don't want to hear the conversations developers might have, internally or with Agents, the customer only cares about what the Agent tells them really, and there are many cases where a customer should not know (let alone care about) what is happening internally.  But when you have developers who are also customers, what is the problem with sharing all the info with them?

[Tim Jedlicka]

I think I'm starting to see our disconnect - we are not a Agent/Developer/Customer(external) model - instead we are a DevSupport/User model - I support the development environment (servers, networking, ...) for 100's of JSW projects.

Development/environment support == Service Desk Agents (IT helpdesk)
Developers == Users (aka our "customers" - but they all have JSW JIRA access)
No external customers are involved.

We had been supporting our Users (the developers of THEIR product) using JSW-JIRA. Recently we have been trying to move to JSM since we are really a support org not a development org. There are several JSM features that are better suited for a support desk (confluence links, Insight, SLAs,...). Our users work with JIRA everyday, so they are very familiar with the interface so they will interact and comment on JSM tickets via JIRA (versus the customer portal) - just as they have been for years now.

There are times when it would be useful for the Agents to have a discussion about a User's issue without the User seeing the discussion. i.e.

• "Agent Team - this is the third time this user has broken the system. I feel we should revoke their root access to this server. Does the rest of the team agree or is there a better solution?"
• "Agent Team -Project Y is requesting 128 IP addresses. I can't understand why they need so many. Has anyone else seen a similar setup?"
• "Project X has a critical need for the new server that just came in - is anyone willing to work over the holiday to get it installed?"

[Nic Brough -Adaptavist-]

That makes a lot of sense, and yes, there is a bit of a disconnect.

There is a simple way to think about it though.  You say

"Recently we have been trying to move to JSM since we are really a support org not a development org"

There's a simple way to do it.  In Jira-speak, start treating your internal developers as though they really are customers.  They have accounts which let them into the projects they use as developers, but also into your service-management projects.  Just remove their project access to the JSM projects.  They will then only be able to see the requests and "external" comments, your agents will be able to converse in private in the internal comments.

The easy way to do this is just removing their access to browse the projects in the permission scheme.  If you want to let them see some of the issues, you could do it with issue security instead, but that does mean your agents would have to understand why and how to set the security level on issues.

[Linda Wanitschek]

Jon, yes it takes them to Jira, but their user security will only let them do x, so we are okay with that.  They still cannot see the internal comments.  

Not all apps are perfect. We struggle to with what should the reporter be able to see or not, and yes the service desk team members have to do the fixes.  But we have over 3500 people in our instance and haven't had any slip ups. knock on wood.  

[Jeanne Scilley]

Hello Linda.  How are you able to hide internal comments from your users who view the tickets in the JIRA application? 

Our SD is internal to our company - we do not use it for persons who buy our products - our SD "customers" are business users who seek IS support inside the company.   We have a mix of business users - some of which are JIRA savy and actually use JIRA core/software for their projects and project management.  Because they are familiar with JIRA they do not use the portal to check the status of their service desk tickets - they work/comment directly in the service desk tickets

It would be nice if there was a way that we could hide the Internal comments for those users who are not agents in the service desk.  

I would be interested to know if I understood your last comment to mean that your employees who are not service desk agents cannot see the internal comments in that service desks tickets.  And if so, whats the magic trick?  ;-)

[Jan Clausen]

Hi,

I would also like to know if there is some posibility to make the internal notes in SD "private"

so that only assignee or board administrator can see them.

Not all other company users

Is it possible

[Nic Brough -Adaptavist-]

No, if you can see the issue, you can see the internal comments.

[Sverre Moe]

We would like to know this also

We have JIRA users (external customers) with access to a Service Desk Project, but we do not want them to read the INTERNAL comments.

[Kevin Black]

Many of our small cohort (ATM) do not go into Portal View after creating the issue. They simply rely on the flow of emails to and from Service Desk.

QUESTION: If a service desk agent creates an internal note which of these (are supposed to) get an email (they all would if it were a share with customer):

• Reporter
• The Other Service Desk Agents
• Requested Participants
• The Assignee

Thanks (it's confusing). I'm happy whichever way it turns out as long as I understand the rules.

Kevin

[Nic Brough -Adaptavist-]

People who can see the request can see the comments intended for the customers

People who can see the issue can see the comments intended for "internal" people (and the comments intended for the customers)