Uploaded image for project: 'Jira Service Management Cloud'
  1. Jira Service Management Cloud
  2. JSDCLOUD-14319

Need customisation option to set default for comments (Internal Comment and Reply to Customer)

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • Issue View
    • None
    • 5,046
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Issue Summary

      Currently, there is no customisation option for making comments (Internal Comment and Reply to Customer) as default.

      The problem is that in the old issue transition experience, "Reply to Customer" is the default option; however, in the new issue transition experience, "Internal Comment" is the default option.

      New Issue transition experience:

      Old issue transition experience:

      The customer wants to have a configuring option based on their use case.

      Workaround

      Currently there is no known workaround for this behavior. A workaround will be added here when available

            [JSDCLOUD-14319] Need customisation option to set default for comments (Internal Comment and Reply to Customer)

            Pinned comments

            Hi all,

            After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards. 

            To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done. 

            Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly. 

            Thanks again for your patience and apologies for the inconvenience this change caused. 

             

            Best regards,

             

            Jehan Gonsalkorale

            Principal Product Manager, Jira Service Management

            Jehan Gonsalkorale added a comment - Hi all, After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards.  To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done.  Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly.  Thanks again for your patience and apologies for the inconvenience this change caused.    Best regards,   Jehan Gonsalkorale Principal Product Manager, Jira Service Management

            All comments

            Hi all,

            After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards. 

            To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done. 

            Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly. 

            Thanks again for your patience and apologies for the inconvenience this change caused. 

             

            Best regards,

             

            Jehan Gonsalkorale

            Principal Product Manager, Jira Service Management

            Jehan Gonsalkorale added a comment - Hi all, After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards.  To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done.  Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly.  Thanks again for your patience and apologies for the inconvenience this change caused.    Best regards,   Jehan Gonsalkorale Principal Product Manager, Jira Service Management

            Greg D added a comment -

            I think the majority of us have always wanted this to be configurable and the people that are now mad are experiencing the pain that other Atlassian customers had when public comments leaked unintentionally before this change. Both groups desire a way to configure it and in both cases it seems like it should be more obvious which type of comment you are writing.

            Not sure if anyone watching here is not already watching the article where I posted on recommending Many More Much Smaller Steps to get this to a better place, but just in case the below workarounds help anyone only here, some things Admins can implement right now:

            • You can turn off the notifications for when customer-visible status changes and when things are resolved in the project
              • That way it is not confusing when agents are just transitioning things around and not publicly commenting (either by mistake from the new default or on purpose because they need to change the status without a proactive notification)
                • I think it would be beneficial for all of these default notifications to be configurable by site admins as starting points for new projects too (customer-visible status changing and defaulting a canceled resolution to message the customer is not preferred)
            • If you have a substantial amount of automation rules available in your limit, you can set up checks to look for comment visibility
              • So you could check if internal = true and at-mention that person that wrote it to double-check it or showcase it in some way or even flip it to public if everything written matching certain criteria should be public
            • You could have many agents work the requests from the portal side with transitions added there
              • This one probably isn't feasible with how queues and dashboards are utilized, but just as an option for some subsets of agents

             

            Greg D added a comment - I think the majority of us have always wanted this to be configurable and the people that are now mad are experiencing the pain that other Atlassian customers had when public comments leaked unintentionally before this change. Both groups desire a way to configure it and in both cases it seems like it should be more obvious which type of comment you are writing. Not sure if anyone watching here is not already watching the article where I posted on recommending Many More Much Smaller Steps to get this to a better place , but just in case the below workarounds help anyone only here, some things Admins can implement right now: You can turn off the notifications for when customer-visible status changes and when things are resolved in the project That way it is not confusing when agents are just transitioning things around and not publicly commenting (either by mistake from the new default or on purpose because they need to change the status without a proactive notification) I think it would be beneficial for all of these default notifications to be configurable by site admins as starting points for new projects too (customer-visible status changing and defaulting a canceled resolution to message the customer is not preferred) If you have a substantial amount of automation rules available in your limit, you can set up checks to look for comment visibility So you could check if internal = true and at-mention that person that wrote it to double-check it or showcase it in some way or even flip it to public if everything written matching certain criteria should be public You could have many agents work the requests from the portal side with transitions added there This one probably isn't feasible with how queues and dashboards are utilized, but just as an option for some subsets of agents  

            Evaldas added a comment -

            a620038e6229 , thank you for commenting - at least we have SOME KIND of answer after MONTHS of ignoring this really painful issue.

            HOWEVER, I agree with others - this should NOT be a temporary solution for 3 months, but a PERMANENT!

            Why? I think we are quite typical JSM users - we have 10 TIMES more Customers than Agents, and that alone should indicate, that we could write 10X more “replies to customer” rather than “internal comments”…

            And it's particularly frustrating when closing (resolving) the tickets, because from 20+k tickets we already have, MOST of them (90-95%) were closed (or should have been closed) with “Response to Customer”, while only very few with “internal comments”.

            To sum up, we use “Respond to customer” at least 100 TIMES more than “Comment Internally” - so why the hell YOU made such a headstrong decision on our behalf, without letting us choose (or consulting us in first place)?

            Really mad with you for such pooor planning...

            Evaldas added a comment - a620038e6229 , thank you for commenting - at least we have SOME KIND of answer after MONTHS of ignoring this really painful issue. HOWEVER, I agree with others - this should NOT be a temporary solution for 3 months, but a PERMANENT! Why? I think we are quite typical JSM users - we have 10 TIMES more Customers than Agents, and that alone should indicate, that we could write 10X more “replies to customer” rather than “internal comments”… And it's particularly frustrating when closing (resolving) the tickets, because from 20+k tickets we already have, MOST of them (90-95%) were closed (or should have been closed) with “Response to Customer”, while only very few with “internal comments”. To sum up, we use “Respond to customer” at least 100 TIMES more than “Comment Internally” - so why the hell YOU made such a headstrong decision on our behalf, without letting us choose (or consulting us in first place)? Really mad with you for such pooor planning...

            Our cases are all internal facing, so Internal Note is hardly used. I really don't understand that Atlassian implemented a change with this impact with giving Administrators the option to select a default of their own choice. Yet another reason to start using ServiceNow.

            Christophe Veuskens added a comment - Our cases are all internal facing, so Internal Note is hardly used. I really don't understand that Atlassian implemented a change with this impact with giving Administrators the option to select a default of their own choice. Yet another reason to start using ServiceNow.

            Doug Johnston added a comment - - edited

            I'm yet another manager whose team has been stung by this in recent months. Giving teams longer to transition to the new paradigm is not an adequate response.

            I have no doubt that there are teams who want the majority of their messages to be "internal". For those teams, the new approach is a better fit.

            But for teams like ours, where 90% of our messages are directly to "customers" and "internal" messages are the rare exception, the new approach is awful. It causes us to think we have sent a message to customers only to realize (sometimes days later) that it was an internal note. This is both embarrassing and frustrating.

            Jira and Service Desk are incredibly configurable in nearly every other way (sometimes annoyingly so). It seems like a small ask to give team members the choice of defaulting to "internal" or "customer". Please reconsider.

            Doug Johnston added a comment - - edited I'm yet another manager whose team has been stung by this in recent months. Giving teams longer to transition to the new paradigm is not an adequate response. I have no doubt that there are teams who want the majority of their messages to be "internal". For those teams, the new approach is a better fit. But for teams like ours, where 90% of our messages are directly to "customers" and "internal" messages are the rare exception, the new approach is awful. It causes us to think we have sent a message to customers only to realize (sometimes days later) that it was an internal note. This is both embarrassing and frustrating. Jira and Service Desk are incredibly configurable in nearly every other way (sometimes annoyingly so). It seems like a small ask to give team members the choice of defaulting to "internal" or "customer". Please reconsider.

            Gambit added a comment -

            Making it like full issue view? Internal / Reply shows before click? Better visual indicators seem necessary when you are on one or the other.

            For those saying agents are making a lot of mistakes, that seems to prove that internal is a better default since they do not seem to be paying close attention. How many times before the change were they emailing nonsense to customers or hitting ctrl+enter and sending half-typed information?

            But with that said, it definitely needs a better visual indicator (muscle memory & no differing the tabs makes it tough). Being able to configure would be helpful for sure.

            Could you launch full issue view style to the screen quickly and then investigate other options?

            Gambit added a comment - Making it like full issue view? Internal / Reply shows before click? Better visual indicators seem necessary when you are on one or the other. For those saying agents are making a lot of mistakes, that seems to prove that internal is a better default since they do not seem to be paying close attention. How many times before the change were they emailing nonsense to customers or hitting ctrl+enter and sending half-typed information? But with that said, it definitely needs a better visual indicator (muscle memory & no differing the tabs makes it tough). Being able to configure would be helpful for sure. Could you launch full issue view style to the screen quickly and then investigate other options?

            Hi,

            Appreciate that Atlassian is recognizing this major mistake and owning it.  However this is the WRONG response:

            "The goal is for this to give you more time to manage the change on your end."

            We're NEVER going to get used to a Jira SERVICE management system defaulting to an internal comment.   Please revert this terrible change.

            Susan

            Susan Hauth [Jira Queen] added a comment - Hi, Appreciate that Atlassian is recognizing this major mistake and owning it.  However this is the WRONG response: "The goal is for this to give you more time to manage the change on your end." We're NEVER going to get used to a Jira SERVICE management system defaulting to an internal comment.   Please revert this terrible change. Susan

            I'm reverting it back for my team, we internally built a Chrome extension to flip it over for our small department - but there needs to be customization to this experience before it is strictly enforced as it goes against itsm workflows that I assume a lot of service desks built with JSM.

            Nicholas Wirth added a comment - I'm reverting it back for my team, we internally built a Chrome extension to flip it over for our small department - but there needs to be customization to this experience before it is strictly enforced as it goes against itsm workflows that I assume a lot of service desks built with JSM.

            "The goal is for this to give you more time to manage the change on your end."

            This is an incorrect response.

            The goal should be for your team to review all the negative feedback and provide a solution that works for everyone.  It was said that customers asked for the resolution to be internal, but I was never polled or asked, and clearly many people here were not.

            Please continue to allow us to opt out until you have a better solution for those who use Service Desk to communicate with CUSTOMERS.
            When we want to have internal notes, such as all the details and steps for how we resolved something, we purposefully make an internal note for our team.

            Why not revert the change and let the orgs who don't use it for customer communication figure out how to manage the process on THEIR end?

            Dena Campasano added a comment - "The goal is for this to give you more time to manage the change on your end." This is an incorrect response. The goal should be for your team to review all the negative feedback and provide a solution that works for everyone.  It was said that customers asked for the resolution to be internal, but I was never polled or asked, and clearly many people here were not. Please continue to allow us to opt out until you have a better solution for those who use Service Desk to communicate with CUSTOMERS. When we want to have internal notes, such as all the details and steps for how we resolved something, we purposefully make an internal note for our team. Why not revert the change and let the orgs who don't use it for customer communication figure out how to manage the process on THEIR end?

            a620038e6229 displaying both fields would technically solve the problem, but being able to set it on a Site, Project, or User level would be preferred.

            Based on that I have reacted with the fire emoji, but I would prefer the option to set it ourselves.
            That would, to me, be the difference between a good enough solution and a good solution.

            Rune Rasmussen added a comment - a620038e6229 displaying both fields would technically solve the problem, but being able to set it on a Site, Project, or User level would be preferred. Based on that I have reacted with the fire emoji, but I would prefer the option to set it ourselves. That would, to me, be the difference between a good enough solution and a good solution.

            Dan Breyen added a comment -

            Why force another click on users by not defaulting it to something? If you provide the Atlassian user the ability to choose, then each Atlassian customer can pick 'Reply To Customer Default' or 'Internal Comment Default' based on what works best for their workflows.  It's evident that there are different use cases by a variety of Atlassian Customers using JSM and some can use the system most efficiently if it defaults to 'Reply To Customer' and other users can default to 'Internal Customer'.  

            Dan Breyen added a comment - Why force another click on users by not defaulting it to something? If you provide the Atlassian user the ability to choose, then each Atlassian customer can pick 'Reply To Customer Default' or 'Internal Comment Default' based on what works best for their workflows.  It's evident that there are different use cases by a variety of Atlassian Customers using JSM and some can use the system most efficiently if it defaults to 'Reply To Customer' and other users can default to 'Internal Customer'.  

            Hi all, 

            82ab375396f9 had a great suggestion:

            Why have a default at all?

            Display both fields to the screen so Agents can add internal and customer visible comment at the same time. Make the internal one shaded yellow as an intuitive visual prompt it is the internal field..

            The issue with defaulting one way or the other is that either way someone's muscle memory is going to be messed up and they will make mistakes.

             

            I would like to know whether the users here would prefer this behaviour on transition screens? Please react with a fire emoji if you agree and a thumbs down if this doesn't meet your needs. 

             

            Thanks, 

             

            Jehan

             

             

            Jehan Gonsalkorale added a comment - Hi all,  82ab375396f9 had a great suggestion: Why have a default at all? Display  both fields  to the screen so Agents can add internal and customer visible comment  at the same time . Make the internal one shaded yellow as an intuitive visual prompt it is the internal field.. The issue with defaulting one way or the other is that either way someone's muscle memory is going to be messed up and they will make mistakes.   I would like to know whether the users here would prefer this behaviour on transition screens? Please react with a fire emoji if you agree and a thumbs down if this doesn't meet your needs.    Thanks,    Jehan    

            Hi 35d48d0d095c and 3b21f807ea4a , I've updated the link to the Community article since posting, this is the correct one

            I appreciate your comments, those of 82bf4b2bd0cf and the others here. We will review this given the feedback before we make a decision. I'm being careful to not overpromise but will push to get the right outcome. 

             

            Best regards,

             

            Jehan

            Jehan Gonsalkorale added a comment - Hi 35d48d0d095c and 3b21f807ea4a , I've updated the link to the Community article since posting, this is the correct one .  I appreciate your comments, those of 82bf4b2bd0cf and the others here. We will review this given the feedback before we make a decision. I'm being careful to not overpromise but will push to get the right outcome.    Best regards,   Jehan

            Hi

             

            Appreciate that you are putting an revert option in for 3 months, but all that does is put us back in a ridiculous position again in 3 months so whats the point.

             

            Clearly the flag NEEDS to be on the plans as there is CLEARY a large number of us out here that are frustrated with the position Atlassian have put us in.

             

            It a Service Desk designed to service CUSTOMERS so where on earth would you turn in into something does't have the CUSTOMER as the default option...

             

             

            Richard Hall added a comment - Hi   Appreciate that you are putting an revert option in for 3 months, but all that does is put us back in a ridiculous position again in 3 months so whats the point.   Clearly the flag NEEDS to be on the plans as there is CLEARY a large number of us out here that are frustrated with the position Atlassian have put us in.   It a Service Desk designed to service CUSTOMERS so where on earth would you turn in into something does't have the CUSTOMER as the default option...    

            a620038e6229 

            In essence your post is just giving us 3 month to "get used" to a change we don't want.

            How is this going to help?
            Instead of having the issues we are now facing we will instead be facing them in three months.
            It's not like the problem goes away.

            Please consider the brilliant suggestion from 82ab375396f9 and have both fields available in the same screen.
            Simple solution, easy to implement... problem solved.

            And btw. I also cannot access the link to the Community article.

            Kim Nielsen added a comment - a620038e6229   In essence your post is just giving us 3 month to "get used" to a change we don't want. How is this going to help? Instead of having the issues we are now facing we will instead be facing them in three months. It's not like the problem goes away. Please consider the brilliant suggestion from 82ab375396f9 and have both fields available in the same screen. Simple solution, easy to implement... problem solved. And btw. I also cannot access the link to the Community article.

            a620038e6229 Thank you for the update.

            I will very much urge you to revert or somehow implement a flag.
            The current situation goes against every customer service fiber in my body.
            It is causing a lot of unnecessary confusion and frustration. 

            Also:
            The link to the Community article does not work for me.
            I get a "Nothing to see here... You don't have sufficient privileges to view this page." message.

            Is it perhaps posted in a restricted group?

            Rune Rasmussen added a comment - a620038e6229 Thank you for the update. I will very much urge you to revert or somehow implement a flag. The current situation goes against every customer service fiber in my body. It is causing a lot of unnecessary confusion and frustration.  Also: The link to the Community article does not work for me. I get a "Nothing to see here... You don't have sufficient privileges to view this page." message. Is it perhaps posted in a restricted group?

            Jehan Gonsalkorale added a comment - - edited

            Hi all, 

            I am very aware that this is an inconvenience to you and would like to apologise for not rolling out this change with more notice. 

            To make this easier, we are going to let you opt-in to have the behaviour reverted for three months. 

            The goal is for this to give you more time to manage the change on your end. We will also review the feedback to see whether we will be able to create a flag that lets you set this behaviour within one of our settings pages. This is not something we currently plan on doing, but we will revise the decision before we make the call to revert the behaviour and will, of course, keep you informed. 

            Click here to read the Community article or simply click here to sign up

            Once again, sorry for the inconvenience, we will make sure we handle these changes better next time, letting you know ahead of time. 

             

            Best regards,

             

            Jehan Gonsalkorale

            Principal Product Manager, Jira Service Management

            Jehan Gonsalkorale added a comment - - edited Hi all,  I am very aware that this is an inconvenience to you and would like to apologise for not rolling out this change with more notice.  To make this easier, we are going to let you opt-in to have the behaviour reverted for three months.  The goal is for this to give you more time to manage the change on your end. We will also review the feedback to see whether we will be able to create a flag that lets you set this behaviour within one of our settings pages. This is not something we currently plan on doing, but we will revise the decision before we make the call to revert the behaviour and will, of course, keep you informed.  Click here to read the Community article or simply click here to sign up .  Once again, sorry for the inconvenience, we will make sure we handle these changes better next time, letting you know ahead of time.    Best regards,   Jehan Gonsalkorale Principal Product Manager, Jira Service Management

            I've sent a support ticket on the subject, used the embedded comment, but since two weeks complete radio silence and in the meantime I keep having unhappy clients who complain they don't receive any feedback. And how can I blame my team for this obviously counterintuitive setup?

             

            Atlassian please do something ASAP.

             

            Thank you

            Moix Jacques added a comment - I've sent a support ticket on the subject, used the embedded comment, but since two weeks complete radio silence and in the meantime I keep having unhappy clients who complain they don't receive any feedback. And how can I blame my team for this obviously counterintuitive setup?   Atlassian please do something ASAP.   Thank you

            Yes, please either revert to original "Reply to Customer" function or give Admin ability to set the behavior at project level. 

            David Pellecchia added a comment - Yes, please either revert to original "Reply to Customer" function or give Admin ability to set the behavior at project level. 

            Please roll this back to how it was before.

            Thank you for your consideration.

            Hillary Soita added a comment - Please roll this back to how it was before. Thank you for your consideration.

            Please revert this. This change has resulted in an enormous amount of extra work, customers missing resolution details, and just generally horrible results for about 80% of our interactions.

             

            Ideally there should be a setting for the default response type, but getting us at least back to functional in the mean time is critical.

             

            Thanks.

            -Jeff

             

            jeff.thomas added a comment - Please revert this. This change has resulted in an enormous amount of extra work, customers missing resolution details, and just generally horrible results for about 80% of our interactions.   Ideally there should be a setting for the default response type, but getting us at least back to functional in the mean time is critical.   Thanks. -Jeff  

            Greg D added a comment -

            It seems like all of the defaults in a JSM project when you first set it up compound the issue for people here. In most use-cases that we have, you don't always need to be notifying everyone of all of the status changes nor when it is resolved in all cases (some things may be getting marked canceled without needing a message to go out). You can set up automation to notify in the proper scenarios with messages around what exactly was resolved.

            I was under the impression that the new transition screen would have comments just like the full issue view where you would click into which one you wanted, with the internal side opening if you use the hot-key of "m" and maybe introducing a newer complex hot-key of ctrl/cmd+m or something for reply to customer to open that side. And then if the internal side is opened, it would have a yellow background while typing and include the tool-tip text that your comments will not be visible in the portal (like old view does).

            Greg D added a comment - It seems like all of the defaults in a JSM project when you first set it up compound the issue for people here. In most use-cases that we have, you don't always need to be notifying everyone of all of the status changes nor when it is resolved in all cases (some things may be getting marked canceled without needing a message to go out). You can set up automation to notify in the proper scenarios with messages around what exactly was resolved. I was under the impression that the new transition screen would have comments just like the full issue view where you would click into which one you wanted, with the internal side opening if you use the hot-key of " m " and maybe introducing a newer complex hot-key of ctrl/cmd+m or something for reply to customer to open that side. And then if the internal side is opened, it would have a yellow background while typing and include the tool-tip text that your comments will not be visible in the portal (like old view does).

            Please roll this back to how it was before. This is an extra step for our agents which they didn't consider the first day and caused much trouble. And probably will cause in a future as you may be forgetting about this.

            Sergi Folch added a comment - Please roll this back to how it was before. This is an extra step for our agents which they didn't consider the first day and caused much trouble. And probably will cause in a future as you may be forgetting about this.

            Why have a default at all?

            Display both fields to the screen so Agents can add internal and customer visible comment at the same time. Make the internal one shaded yellow as an intuitive visual prompt it is the internal field..

            The issue with defaulting one way or the other is that either way someone's muscle memory is going to be messed up and they will make mistakes.

            James Rickards (Spark-Nel) added a comment - Why have a default at all? Display both fields to the screen so Agents can add internal and customer visible comment at the same time . Make the internal one shaded yellow as an intuitive visual prompt it is the internal field.. The issue with defaulting one way or the other is that either way someone's muscle memory is going to be messed up and they will make mistakes.

            Hi fc929252228c . a84c7fd9f5bf 

            You can raise a support ticket with Atlassian to have the feature turned off and that will disable it for everyone.   They say it will stay turned off until they can add in assets to the transition screen as that is a missing feature.  I'm really hoping that they hear our alarm and concerns about this new default and either switch it back OR give us the option to default to customer reply for all our agents for our Jira instances. 

            Susan

            Susan Hauth [Jira Queen] added a comment - Hi fc929252228c . a84c7fd9f5bf   You can raise a support ticket with Atlassian to have the feature turned off and that will disable it for everyone.   They say it will stay turned off until they can add in assets to the transition screen as that is a missing feature.  I'm really hoping that they hear our alarm and concerns about this new default and either switch it back OR give us the option to default to customer reply for all our agents for our Jira instances.  Susan

            Anyone wanting to at least temporarily to default to respond to customer can do so by going into their Jira settings (https://dwc.atlassian.net/jira/settings/personal/general)

            Once in there scroll down to the Jira Labs section. Where it says "New issue transition experience" there is a toggle, click on the toggle to revert back. I've had to do this numerous times. It expires / reverts you back on 2/17/25, but at least it's a temporary solution we've been forced to use.

            Dan Heffernan added a comment - Anyone wanting to at least temporarily to default to respond to customer can do so by going into their Jira settings ( https://dwc.atlassian.net/jira/settings/personal/general) Once in there scroll down to the Jira Labs section. Where it says "New issue transition experience" there is a toggle, click on the toggle to revert back. I've had to do this numerous times. It expires / reverts you back on 2/17/25, but at least it's a temporary solution we've been forced to use.

            Our support team got hit with the default to Internal today.

            It basically creates an unwanted extra step.

            Please default the comments to resolve an issue to our customer to "Reply to Customer" instead of "Internal".

            Or grant/create the ability for us to choose our own default on the subject.

             

            Thank you,

             

            Keith Isaacs added a comment - Our support team got hit with the default to Internal today. It basically creates an unwanted extra step. Please default the comments to resolve an issue to our customer to "Reply to Customer" instead of "Internal". Or grant/create the ability for us to choose our own default on the subject.   Thank you,  

            Dena Campasano added a comment - - edited

            It is absolutely insane to me that the change to default to internal was approved for release.  Jira Service Desk is for communicating with customers.  It should have stayed in the backlog until you had a solution that benefited everyone.  Do better.

            Meanwhile we still don't have a field for Assignee on the Customer View.  The prioritization there is wild.

            Dena Campasano added a comment - - edited It is absolutely insane to me that the change to default to internal was approved for release.  Jira Service Desk is for communicating with customers.  It should have stayed in the backlog until you had a solution that benefited everyone.  Do better. Meanwhile we still don't have a field for Assignee on the Customer View.  The prioritization there is wild.

            We need a better way to distinguish between the two options.

            Either we get the option to choose our default in our preferences,

            or the whole field will be colored yellow when it is going to be sent as internal (as the history list will also show internal comments in yellow).

            Ardjan Besse added a comment - We need a better way to distinguish between the two options. Either we get the option to choose our default in our preferences, or the whole field will be colored yellow when it is going to be sent as internal (as the history list will also show internal comments in yellow).

            If I wanted to add an internal comment, I'd leave an internal comment on the ticket.  When I close a customer's issue, the customer should see the reason why.  I can't imagine my thought process is particularly rare here??

            Alexander Ray added a comment - If I wanted to add an internal comment, I'd leave an internal comment on the ticket.  When I close a customer's issue, the customer should see the reason why.  I can't imagine my thought process is particularly rare here??

            c7411bbb0ba5 I think that would be a useful feature. But we’d want to have that as one of the options configurable at the transition+field level. Otherwise, transitions which must always provide a public facing comment cannot be configured properly.

            Though, honestly, where is the option to allow the user to submit both an internal and a public comment at the same time? In some transitions, requiring both would make sense. Since I don’t have admin access to any Jira instance at the moment, I can’t play with it, but this gives me the impression that the whole comment-adding transition field is either internal or public or omitted but there wouldn’t be a way to add both an internal and public comment at the same time even if it logically made sense to do so.

            Nathan Phillip Brink added a comment - c7411bbb0ba5 I think that would be a useful feature. But we’d want to have that as one of the options configurable at the transition+field level. Otherwise, transitions which must always provide a public facing comment cannot be configured properly. Though, honestly, where is the option to allow the user to submit both an internal and a public comment at the same time? In some transitions, requiring both would make sense. Since I don’t have admin access to any Jira instance at the moment, I can’t play with it, but this gives me the impression that the whole comment-adding transition field is either internal or public or omitted but there wouldn’t be a way to add both an internal and public comment at the same time even if it logically made sense to do so.

            The Issue View screen uses this mechanism for adding comments:

            The agent must click either internal or reply to customer – forcing them to make a choice of what type of comment to add.

            Do the same for comments in the transition screen.

            No defaults. No user preference. No project-wide preference. No site-wide preference.

            Simple and consistent.

            Please a620038e6229

            Andrew Culver added a comment - The Issue View screen uses this mechanism for adding comments: The agent must click either internal or reply to customer – forcing them to make a choice of what type of comment to add. Do the same for comments in the transition screen. No defaults. No user preference. No project-wide preference. No site-wide preference. Simple and consistent. Please a620038e6229

            I see this as a regression and bad engagement from a JSM customer perspective. No ticket should be closed without comment to customer. What is unfortunately happening. I make a mistake closing with internal, then have to comment again (reply to customer), this reopens the ticket and I have to close it again. 

            Please revert to "a good customer service approach" in this dialog ASAP. And then work out internally how to fix the "choice".

             

             

            Rudi Heitbaum added a comment - I see this as a regression and bad engagement from a JSM customer perspective. No ticket should be closed without comment to customer. What is unfortunately happening. I make a mistake closing with internal, then have to comment again (reply to customer), this reopens the ticket and I have to close it again.  Please revert to "a good customer service approach" in this dialog ASAP. And then work out internally how to fix the "choice".    

            See: https://community.atlassian.com/t5/Jira-Service-Management/Re-Resolve-this-issue-now-defaulting-to-quot-Add-internal-no/qaq-p/2900336/comment-id/190227#M190227  for a comment from the Product Owner (Jehan) to start to work out how to address this in January.

            Due to how long this has taken, many of our team will have new muscle memory that comments default to internal. IMO when Atlassian rolls this out it needs to be configurable at the individual user preference screen by users.  Otherwise, if it gets rolled out globally by me changing it at the server level, someone is going to mess up and make internal comments public.

            Initially I also wanted for us admins be able to set this on every transition allowing us to pick and choose based on the context the screen is displaying in (e.g. on a transition to handover between internal teams the default should be internal, whilst resolution screen this should be customer visible).  This would require an update to the workflow engine, and could result in admins creating inconsistent behaviour for users leading to users making mistakes easier. After really sitting down and thinking about it, I now think that making this very configurable would be a bad idea.

            I'm interested in other peoples thoughts...

            React with:

            • thumbs up for the simple "KISS just let people set their own preference" and be done with it.
            • Heart eyes emoji for "middle ground" let me set a default at the server level, and let people overwrite it.
            • Fire react for "I want full control at the transition level" Atlassian should give me enough rope to build a ladder to success or a noose to hang my team.

            James Rickards (Spark-Nel) added a comment - See: https://community.atlassian.com/t5/Jira-Service-Management/Re-Resolve-this-issue-now-defaulting-to-quot-Add-internal-no/qaq-p/2900336/comment-id/190227#M190227   for a comment from the Product Owner (Jehan) to start to work out how to address this in January. Due to how long this has taken, many of our team will have new muscle memory that comments default to internal. IMO when Atlassian rolls this out it needs to be configurable at the individual user preference screen by users.  Otherwise, if it gets rolled out globally by me changing it at the server level, someone is going to mess up and make internal comments public. Initially I also wanted for us admins be able to set this on every transition allowing us to pick and choose based on the context the screen is displaying in (e.g. on a transition to handover between internal teams the default should be internal, whilst resolution screen this should be customer visible).  This would require an update to the workflow engine, and could result in admins creating inconsistent behaviour for users leading to users making mistakes easier. After really sitting down and thinking about it, I now think that making this very configurable would be a bad idea. I'm interested in other peoples thoughts... React with: thumbs up for the simple "KISS just let people set their own preference" and be done with it. Heart eyes emoji for "middle ground" let me set a default at the server level, and let people overwrite it. Fire react for "I want full control at the transition level" Atlassian should give me enough rope to build a ladder to success or a noose to hang my team.

            Please add the ability to choose between the 2 options.  Thanks!

            Leandro Guichot Reina added a comment - Please add the ability to choose between the 2 options.  Thanks!

            Ali Sipit added a comment -

            this is a joke, Even support staff says that the opt-out is only temporary. How hard is it to just make it configurable. Ridiculous change and I highly question that 'most customers want internal first'. Since when does Atlassian even ask for customer feedback.

            '

            As per DEV team New Issue transition screen will be the default one going forward in near future and old UI will be deprecated completely.

            However In order for users to get adequate time to have new experience , you will able to Toggle ON/OFF as many number of times you can. After March , you can again opt out for new UI.

            As mentioned , Internal Comment is made default in New issue transition to have same consistency between Agent View/Issue view and the transition screen.

            '

            Ali Sipit added a comment - this is a joke, Even support staff says that the opt-out is only temporary. How hard is it to just make it configurable. Ridiculous change and I highly question that 'most customers want internal first'. Since when does Atlassian even ask for customer feedback. ' As per DEV team New Issue transition screen will be the default one going forward in near future and old UI will be deprecated completely. However In order for users to get adequate time to have new experience , you will able to Toggle ON/OFF as many number of times you can. After March , you can again opt out for new UI. As mentioned , Internal Comment is made default in New issue transition to have same consistency between Agent View/Issue view and the transition screen. '

            e04b1c14a080 It's the modern age of software development.
            Crank out half-baked shit to meet minimum requirements and then ignore it for the next 5-8 years.

            Rune Rasmussen added a comment - e04b1c14a080 It's the modern age of software development. Crank out half-baked shit to meet minimum requirements and then ignore it for the next 5-8 years.

            when this will be solved? This needs to be configurable in the system!

            Artjoms Gusevs added a comment - when this will be solved? This needs to be configurable in the system!

            Please add the ability to choose between the 2 options.  Thanks!

            Andrew Collins added a comment - Please add the ability to choose between the 2 options.  Thanks!

            I agree. Toggling off New Issue Transition Experience is a stop gap measure. It's a workaround (for now) but we may not have that option once it expires.

            Dan Heffernan added a comment - I agree. Toggling off New Issue Transition Experience is a stop gap measure. It's a workaround (for now) but we may not have that option once it expires.

            c41c71995e06 You can turn it off for now, but we'll just have this problem again in March unless Atlassian fixes it.

            Anthony Pereira added a comment - c41c71995e06 You can turn it off for now, but we'll just have this problem again in March unless Atlassian fixes it.

            If anyone still struggling with that you can simple switch of the toggle for New Issue Transition Experience in you Personal  Account Settings if you rather use the old solution. BR

            Fabian Plattner added a comment - If anyone still struggling with that you can simple switch of the toggle for New Issue Transition Experience in you Personal  Account Settings if you rather use the old solution. BR

            Had requests on switching back to External as default as soon as the new experience had been rolled out on our site. I get that there are different needs around that and would love to see an option to change the default per Site, project or even better: User!

            Rebekka Heilmann (viadee) added a comment - Had requests on switching back to External as default as soon as the new experience had been rolled out on our site. I get that there are different needs around that and would love to see an option to change the default per Site, project or even better: User!

            +1

            David Israel added a comment - +1

            For anyone struggling with the new issue experience: You can ask Atlassian support to disable it on your site(s). I strongly recommend to mention this ticket in your request.

            Birger Robrecht [avono AG] added a comment - - edited For anyone struggling with the new issue experience: You can ask Atlassian support to disable it on your site(s). I strongly recommend to mention this ticket in your request.

            Why??   OMG, do you know how many of our agents are going to get really upset about having to flip this to "reply to customer" OR worse forgetting to do so and wondering why the requester didn't receive the update.    WHY do you roll out changes that force us into a really BIG change of process without any option to set a default. WHY??

            I now have to send an email to ALL our agents to NOT go to the new issue transition experience.

            Susan Hauth [Jira Queen] added a comment - Why??    OMG, do you know how many of our agents are going to get really upset about having to flip this to "reply to customer" OR worse forgetting to do so and wondering why the requester didn't receive the update.    WHY do you roll out changes that force us into a really BIG change of process without any option to set a default. WHY ?? I now have to send an email to ALL our agents to NOT go to the new issue transition experience.

            This needs to configurable in the system.  The MAY be some that want it to default to internal but I would think that based on this being a CUSTOMER communication tool to update CUSTOMERS in ticket progress, It make no sense at all why it defaults to internal.

            Not sure who makes the decisions about what changes are made but this has clearly been something which is a fundamental change, and to make the change and not provide and option to select the default is one of bad judgement.

            Please resolve this issue as it causes no end of problems.

            Richard Hall added a comment - This needs to configurable in the system.  The MAY be some that want it to default to internal but I would think that based on this being a CUSTOMER communication tool to update CUSTOMERS in ticket progress, It make no sense at all why it defaults to internal. Not sure who makes the decisions about what changes are made but this has clearly been something which is a fundamental change, and to make the change and not provide and option to select the default is one of bad judgement. Please resolve this issue as it causes no end of problems.

            Tania Hale added a comment -

            This shouldn't be by default. Our customers are internal and are not getting replies to tickets due to this default option being changed. Many still forget to change it to Reply to Customer when closing a ticket which creates frustration on the customer side, when they only receive ticket is closed , without any explanation 

            Tania Hale added a comment - This shouldn't be by default. Our customers are internal and are not getting replies to tickets due to this default option being changed. Many still forget to change it to Reply to Customer when closing a ticket which creates frustration on the customer side, when they only receive ticket is closed , without any explanation 

            We want it to be set to internal by default, but we also understand UX. Please make this configurable per instance or per project.

            Anne Saunders added a comment - We want it to be set to internal by default, but we also understand UX. Please make this configurable per instance or per project.

            +1 Most comments in a SD Project are external. 

            Ken Roundtree added a comment - +1 Most comments in a SD Project are external. 

            +1

            Multiple customers are not getting replies to tickets due to this default option being changed. It went unnoticed for a month within our team.
            Instead of changing the default yourselves, give your customers the ability to set the default option themselves.

            Rob McCulloch added a comment - +1 Multiple customers are not getting replies to tickets due to this default option being changed. It went unnoticed for a month within our team. Instead of changing the default yourselves, give your customers the ability to set the default option themselves.

            This new internal note default continues to be a major headache. This change basically sabotaged our work flow. I'm repeatedly replying to confused and frustrated customers who didn't receive a comment and only got a "resolved" email. God knows how many customers were left frustrated and didn't bother attempting to reply. 

            Dave Deenik added a comment - This new internal note default continues to be a major headache. This change basically sabotaged our work flow. I'm repeatedly replying to confused and frustrated customers who didn't receive a comment and only got a "resolved" email. God knows how many customers were left frustrated and didn't bother attempting to reply. 

            For Atlassian to change this habitual workflow that users have been accustomed to for years is an incredibly poor design choice especially without the ability to manage it. It's the staff actioning tickets AND the customers expecting public comment responses that are negatively affected by this change. Posting a single comment now requires mental effort, quite a lot to ask. How was this not thought through? 

            +1 

            Kimberly Kane added a comment - For Atlassian to change this habitual workflow that users have been accustomed to for years is an incredibly poor design choice especially without the ability to manage it. It's the staff actioning tickets AND the customers expecting public comment responses that are negatively affected by this change. Posting a single comment now requires mental effort, quite a lot to ask. How was this not thought through?  +1 

            Joe added a comment -

            +1

            Joe added a comment - +1

            Steve C added a comment -

            Highly recommend reverting change JSDCLOUD-1733 Make Internal Comments the default comment type - Create and track feature requests for Atlassian products.

            Then implement this "customisation option to set default for comments" first.

            Reply to customer on ticket close is Helpdesk 101. Now you have simply flipped opinion of the requirement of "Reply to Customer" needing to be the default option and as it was prior to this mid-Dec 2024 change.

            Steve C added a comment - Highly recommend reverting change JSDCLOUD-1733 Make Internal Comments the default comment type - Create and track feature requests for Atlassian products. Then implement this "customisation option to set default for comments" first. Reply to customer on ticket close is Helpdesk 101. Now you have simply flipped opinion of the requirement of "Reply to Customer" needing to be the default option and as it was prior to this mid-Dec 2024 change.

            +1 vote

            HR GENE SOLUTIONS added a comment - +1 vote

            This is extremely painful, first off, I now have no Idea how many clients have just received "Resolved" emails with zero explanation as all the comments are internal, luckily I responded to a ticket today and noticed once done that it was Internal which raised a flag in my mind.

            Should anyone want to add an internal/sensitive information, they can do so on the main ticket screen, the whole process of "Responding to Customer" is to respond to Customer, not create an internal comment.

            I believe adding internal notes should be its own category if accidentally sharing sensitive information is a major concern. Maybe that should be looked into as a resolution?

            Anthony Bloom added a comment - This is extremely painful, first off, I now have no Idea how many clients have just received "Resolved" emails with zero explanation as all the comments are internal, luckily I responded to a ticket today and noticed once done that it was Internal which raised a flag in my mind. Should anyone want to add an internal/sensitive information, they can do so on the main ticket screen, the whole process of "Responding to Customer" is to respond to Customer, not create an internal comment. I believe adding internal notes should be its own category if accidentally sharing sensitive information is a major concern. Maybe that should be looked into as a resolution?

            Ditto to all the other comments. At least make this configurable, please. 

            Christel Gray added a comment - Ditto to all the other comments. At least make this configurable, please. 

            Having 'Internal Comment' be the default for Agents adds more time to creating the reply.  The majority of the time Agents are replying to customers, not making internal comments.  'Reply to Customer' should be the default, for Agents.  

            Dan Breyen added a comment - Having 'Internal Comment' be the default for Agents adds more time to creating the reply.  The majority of the time Agents are replying to customers, not making internal comments.  'Reply to Customer' should be the default, for Agents.  

              a620038e6229 Jehan Gonsalkorale
              dcf888be292f Tanmay Tandon
              Votes:
              449 Vote for this issue
              Watchers:
              250 Start watching this issue

                Created:
                Updated: