Creating a more cohesive Assist experience in Slack

[#1]

Update: Thank you to all the customers that have shared feedback with us on these changes. We want to announce that we’ve decided to keep the lock emoji (🔒) functionality for adding internal notes on tickets from agent channels in Slack.

We plan to introduce the new internal note functionality as an additional way to add internal notes from Slack in a future release.

Hi everyone,

As we approach Halp’s end of life on June 4, 2024, we’re making a few more experience changes to Jira Service Management chat for Slack. These updates align the chat experience closer to Jira Service Management, making it easier for everyone to use Assist.

How to use this blog

Each change has its own section detailing who’s affected, what’s changing, how to prepare, and dates to remember. This post only details Slack changes — if you use Microsoft Teams and Assist, read more about your changes here.

Depending on your settings, and if you migrated to Jira Service Management from Halp, you may not see all these experience changes.

We plan to roll out the bulk of these changes on February 29, 2024, with the final updates coming March 27, 2024.

Request channels must have at least one request type added

Who does this affect?

All admins, and any new service projects you connect to Slack.

What’s changing?

With this update, when you create a request channel in Slack, you must connect a request type to it. Until you connect a request type, no one can raise a request in that channel.

If you have a request channel with no added request types, we’ll connect them all for you. You can remove them from your chat settings as needed. This is a one-time migration to support this change — in the future, you need to connect request types when setting up a new channel.

With this change, you no longer have to mark a request type as hidden in settings. As long as a request type isn’t connected to a request channel, requesters can’t use it in Slack. If a request for that type is raised elsewhere, like through web or email, it still routes to the connected agent channel.

What should I do to prepare?

1. Review your request channels and make sure that you have the appropriate request types connected.

2. If you use hidden request types, make sure they aren’t connected to any request channels before February 29, 2024.

Dates to remember

Feb 29, 2024: Request channels without added request types connect to every request type in the project. Any new request channels created after this date require you to connect to a request type.

Agent replies now default to public

Who does this affect?

Migrated former Halp customers who have agent replies defaulted to private.

What’s changing?

Some migrated Halp customers use a setting where agent replies default to private, rather than public comments. Starting on March 27, 2024, we’re removing this setting. This means all replies will default to public, and there won’t be a way to switch back to private as the default.

To send an internal note from the agent channel, agents can start their message with the lock emoji (🔒), then enter the rest of their note and send.

We’ll remind agents through whisper Slack messages (that only appear to them) that this change is coming as it requires a slight behavior shift.

What should I do to prepare?

If you use this setting, let your agents know they need to use the lock emoji (🔒) to add private comments. We’ll remove the setting on March 27, but you can turn it off earlier if desired.

Dates to remember

• Feb 29, 2024: Assist starts sending whisper Slack messages to agents to tell them that their comments will soon default to public. We’ll also remind them to use the lock emoji to send private comments.
• Mar 27, 2024: Setting removed from Halp web, all agent replies default to public.

Agents can only edit issues from agent channels

Who does this affect?

Migrated former Halp customers who allow requesters to edit tickets.

What’s changing?

Halp has a setting that allows anyone to edit a request in a request channel or app home. This leads to confusion if a requester changes fields after raising a request.

To better capture requests and match Jira Service Management’s behavior, moving forward, requesters can’t edit requests, and only agents can edit issues from agent channels. This means no one can edit a request from a request channel.

What should I do to prepare?

Let your agents know they’ll only see the Edit button from agent channels starting on February 29, 2024. Or, agents can use the issue link from the request channel to open the web view and edit from there.

Date to remember

Feb 29, 2024: Only agents can edit issues from agent channels in Slack.

Removing bot logo customization

Who does this affect?

Migrated former Halp customers who customized their Assist logo in Slack.

What’s changing?

As we move away from Halp’s legacy functionality, migrated customers can no longer upload a custom logo for the Assist bot. All logos will reset to the blue Assist life preserver.

Custom names won’t change as a part of this update. For admins who want to set up a custom bot name, head to Assist’s Configuration in your app management settings, found in your Slack app settings and administration.

Note: If you plan to use Halp until its end of life in June 2024, you can keep your custom logo until then.

What should I do to prepare?

No additional effort is needed from you, but you may want to let your organization or teams know to expect a switch on February 29, 2024.

Date to remember

Feb 29, 2024: Your custom logo is replaced with the Assist blue life preserver.

Two-way issue creation is now default

Who does this affect?

Migrated former Halp customers who have one-way ticket creation to Jira enabled.

What’s changing?

For Halp queues connected to Jira Service Management, there’s a setting called one-way ticket creation. For migrated customers who still have this setting enabled, we’re updating all request types to two-way ticket creation.

What should I do to prepare?

This may mean more issues start appearing in your agent channels. If you don’t want certain issues to appear in your agent channels, you can disconnect the request type before February 29, 2024.

Date to remember

Feb 29, 2024: All projects default to two-way issue creation.

Anyone can raise requests with emoji 

Who does this affect? Migrated former Halp customers who only allowed admins and agents to use the ticket emoji to raise a request

What’s changing? After February 29, 2024, anyone can use the ticket emoji to raise a request. This setting will be removed from Halp web.

What should I do to prepare? No action is needed.

Date to remember

Feb 29, 2024: Anyone can use the ticket emoji to raise a request, regardless of if they’re an admin/agent or not.

Adding internal notes

Based on your feedback, we’ve decided to keep the lock emoji (🔒) functionality for adding internal notes on tickets from agent channels in Slack.

We plan to introduce the new internal note functionality, introducing an Add internal note button to the ticket display in agent channels, as an additional way to add internal notes from Slack in a future release.

Let us know if you have any questions or if anything is unclear — this is a lot of change, and we value your feedback and are here to chat.

[Jeff Hoover]

Thank you for the clarification on the above features.

How about the ability to continue to use Answers in JSM Standard edition?  Atlassian announced last year "all of the features and functionality you know and love will be available in every Jira Service Management Cloud plan", but this does not appear to be true.  It appears you must subscribe to Premium or Enterprise to continue to use the replacement for Answers.

Also, any word on Ticket Recipes?

[Ian Kyslytsya]

What is the reasoning behind the New internal notes experience?

My colleagues (agents) all the time add screenshots as internal notes easily by using the lock emoji. It is also much much easier to write a message in a Slack thread while seeing previous messages above in comparison to clicking a button and typing a message in a window. And for some smart reason all of this doesn't apply to requesters...They can continue to add attachments to their messages. Why not remove this option from them as well??? Maybe Atlassian forgot that Slack is an instant messaging service aka chat and not an email solution. This change/update will force me and my colleagues to stop using the agent channel and imediately switch over to your website.

So to me it seems like all of the recent changes to the Jira ITSM - Slack integration indicate that you are trying to force different types of Jira users (in this update - agents) to go away from Slack and to use your website to work on tickets. 

Then what is the point of having this Jira ITSM - Slack integration at all? Just release a blog post that you have decided to kill this integration and let's all move on with our lives...

Strange behavior from Atlassian considering you already have our money no matter where we work on our tickets...

[Marie Casabonne]

Hi @Jeff Hoover, to get the pre-ticket deflection user experience that Halp Answers provided, you do need to be on JSM premium to utilize the virtual agent. This feature is much more powerful than Halp Answers as it uses a machine learning model tailored to each individual customer & project. You can automate full end-to-end workflows using the virtual agent's flows or leverage Atlassian Intelligence answers that use generative AI to search across your linked knowledge base spaces and answer your customer questions.

You can, alternatively, use keyword matching with Jira Automations (post ticket creation) to send automated responses to help seekers to resolve their issues. This is more similar to how Halp Answers words today, the one difference here is that this would be after a ticket is raised. However, it does not require you to upgrade to JSM premium as Jira Automations are available across all plans. 

Can you expand more on your question re: Ticket recipes? If you're referring to Halp recipes, those can be rebuilt using Jira Automations. We also recently released an emoji based Jira Automation trigger that allows you to build out emoji-triggered automations, tapping into the full power of Jira Automations.

[Tobias H]

Why is the logo for Assist not customizable? Almost all bots within our Slack workspace has their own profile picture that is carefully selected together with a custom name, the Assist bot really sticks out as a sore thumb and makes it much less "friendly".

The blue ring on a white background is as default as it gets, after the silhouette images.

It does not create a welcoming experience for users and blatantly states that it's a bot :/

---

Secondly, what I fail to see in this update is information about how "needy" Assist is.

If a user does not answer the "Are you happy, or do you need help" message it keeps nudging again and again. This is a really unwanted behavior with no available configuration.

Are there any plans to address this?

[Heather Hanchett]

What happens to messages with the lock emoji after March 27th? Will they be public? 

[Ken S]

Hello all, will any of these changes affect the 'Private chat requests' functionality? 

[Jeff Hoover]

It sounds like we are definitely losing one of the features that we know and love then, despite Atlassian announcing otherwise.  Moving to a post ticket key word matching solution for Answers is not the way to go.  Atlassian should do the right thing and honor what they announced instead.

For ticket recipes, yes, I was referring to Halp recipes where you can react with an emoji.  I will take a look at the emoji based Jira Automation trigger, that sounds promising.

[Ricky Jordan]

Gotta love how adding followers to a ticket in Slack STILL doesn't cc or add them to the ticket/slack thread like it did with HALP, so now we have to have "side chatter" group dms outside of the ticket, and then manually add any notes to the ticket later on (smh).  Whomever thought this was good behavior is out to lunch....  Going on 6+ months now with this being shelved and everyone twiddling their thumbs.

It's almost like JSM/Atlassian bought out Halp/Assist to squash the competition and forward thinking approach that made Halp so great and legacy ticket solutions look like they were behind.  The decisions for the Slack app and removing existing things that made it great, are prime examples of that.

I really really want to love the JSM "merger" which should supercharge the existing Slack/Assist/Halp experience, but they keep wanting us to leave Slack and goto the "web view".  For agents this could technically work but for requesters that are internal only (aka internal company ticketing and NOT customer based), who wants to do that?  Assist Home screen "open tickets" view inside Slack, I'm looking at you (or not... since removed lol).

Come on JSM/Assist!  Let's get with the times and innovate, not take multiple steps back.

[Ricky Jordan]

Also adding, that the release schedule date for these changes that could have big impacts on users (especially legacy HALP/ASSIST users), is comical.  You make an announcement today 02/13/24 and the changes are in effect 02/29/24? a little over 2 weeks out?  It's almost forceful and bad etiquette in my eyes, and shows lack of care and a "hot potato" mentality.

Get a good cadence down, get good features (THAT ARE UPGRADES, not downgrades), and you will have a winning product with a happy customer base.  It's not a hard formula....

[Michael from Stax]

I cannot wait to see the impending customer fallout that occurs for so many business once the "Agent replies now default to public" change goes live as I am sure that a lot of other admins will not read this as in a lot of cases, Assist is probably installed by a collective group of end-users, who will inevitably not read about these changes.

There have been several feature requests raised to you about making the replies private by default in assist in place of using the padlock emoji as it is a great way to collaborate on a solution prior to going back to the customer, but it sounds like it will never be worth the risk of using a thread to reply just in case the customer gets visibility of potential solutions or internal data shared to get them the help they require.

[Brandon Witzig]

As someone who has been following along, Atlassian Assist has gone from a smart idea to get people to upgrade subscriptions to jira service premium to "whats the point" now. 

You bought out one of the top vendors in the space, all Atlassian needed to do was refine a few things and it would be a huge draw to the Atlassian ticketing systems as a whole. 

With these feature reductions, it makes it much harder to recommend vs the competition. 

[Brian Feldman]

Hey all, thank you for you questions and feedback! I want to share some more details & background around the change to Internal Notes for agents and why we believe this is an upgrade for the majority of our user base. I understand this might not be the preference for all users, but I hope this at least provides some transparency around our approach and the reasons for the change.

Today, <5% of total comments added by agents via Assist are Internal Notes. The vast majority are public comments. We wanted to better understand why. In speaking with customers, we found a few common themes:

• Using the  emoji was not a common, intuitive pattern in Slack
• For a sharing sensitive information, prepending a  did not evoke a sense of confidence in what the resulting action would be. Many felt it was “hacky” and prone to error. Either human error (i.e. a similar looking emoji was added, but with wrong name. Or the emoji was not placed in the right location). Or software error (as it relies on text parsing as opposed to a more deterministic technique)
• The default setting could be changed between teams / sites (i.e. in workspace-a, comments default to private. But in workspace-b, a  is required). In many cases, agents work across multiple teams / workspaces / sites, and therefore it becomes difficult to predict what the behavior would be in a given channel. In this situation, internal notes are seen as a risky action to attempt via Slack, one that agents would rather avoid all together vs taking a risk
• Many agents monitor both the request channel and the agent channel. This results in scenarios where agents accidentally reply publicly via the request channel when they intended to add an internal note

To address these concerns around low trust, confidence, predictability, and adoption of internal notes in Slack, we are introducing a more formal experience for adding them. One that will result in more predictable outcomes for all agents in all channels.

Attachments in internal notes is something we’d like to be able to continue supporting. We are actively following feature requests for Slack to add support for attachments via modals which would enable us to do so.

Also a point of clarification: these changes will only affect comments moving forward. No historical comments / internal notes will be impacted.

[Joseph Whyle]

Hi Brian, 

I think the change is definitely one which I am a bit miffed on. It was a simple feature that could be used and definitely sped up ones workflow. 

When you say <5% of total comments added by agents via Assist are Internal Notes, when was this measured? Is this since Atlassian bought the product or is this over a longer period of time? 

Secondly regarding trust and confidence, I get that but couldn't you just put sufficient guard rails in place to try reduce those edge cases. I love this feature and use it a lot so an extra click here seems annoying. 

At least give us the ability to put an emoji in to open the internal note input box. 

[Brian Feldman]

Hi @Ken Szymanski -- no, these changes do not impact 'Private chat requests'

[Andy Conley]

As an organization that recently adopted Jira Service Management (JSM) for our support desk, we embarked on this journey aiming to enhance our customer support experience. Historically, our support framework operated without direct customer interaction, focusing on internal collaboration between our Tier 2 and Tier 3 teams to resolve issues. The introduction of JSM was a strategic move to bridge this gap, allowing customers to submit and monitor their tickets directly through the portal.

However, we've encountered significant challenges that impede our goal of a seamless customer support experience:

1. Slack Integration and Comment Visibility: A critical issue arises from the integration of Slack with JSM. The default setting for Slack comments to be public poses a significant risk, as it relies heavily on our support staff's vigilance to manually mark each comment as internal. This not only introduces room for human error but also detracts from the efficiency of our support process.

2. Lack of Dynamic Portal Request Forms: The inability to differentiate portal request forms for internal versus external users limits our capability to provide a tailored and intelligent support experience. Our vision of smart forms that dynamically adjust based on the user type remains unfulfilled. The workaround of managing two separate JSM projects introduces unnecessary complexity and inefficiency into our support operations.

In light of these challenges, we propose specific inquiries and suggestions to Atlassian:

• Automation for Internal vs. Public Comments: Will Atlassian introduce methods to automate the classification of Slack-sourced comments as internal? This feature would significantly mitigate the risk of sensitive information being inadvertently shared with customers.

• Support for Third-Party Marketplace Add-ons: Can Atlassian confirm continued support for third-party marketplace add-ons that enable us to modify the default visibility of comments? This support is crucial for maintaining flexibility and control over our customer communications.

• Data-Driven Insights into Comment Practices: Regarding the statistic that less than 5% of comments are added as internal notes, we question the underlying cause. Our contention is that the lack of a default setting for internal-only comments in Slack/JSM integration may contribute significantly to this statistic. The assumption that conversations within a private Slack channel (a requirement enforced by the JSM integration) remain confidential is intuitive within the Slack ecosystem. The absence of a managed approach to designate comments as internal by default undermines the integrity of our customer communications.

To us, customer communication is paramount. The current reliance on manual oversight for comment privacy introduces a risk we are hesitant to accept. We urge Atlassian to consider these points not as mere criticism but as a call to action to enhance JSM's functionality and, by extension, our ability to serve our customers effectively and securely.

[hayato yamazaki]

About Agent Replies Should Be Private

As several helpful users have written, I also think it's very problematic that messages posted in the agent channel are treated as public messages.

If messages are handled on a public basis, there is no point in distinguishing between request channels and agent channels.

The fact that buttons must be operated to register internal comments is also a sure-fire hindrance to smooth communication.

I would like you to remember the meaning of the triage channel, the predecessor of the agent channel.

Handling public messages is a destructive change in specifications that will break existing habits, and the impact on business operations will be immeasurable.

You should leave an option setting that users can choose to treat as private messages. Please give us the options we seek.

I hope that appropriate judgment will be made to prevent this destructive specification change from being applied as it is. Please, please.

[Max Edwards]

Hey @Brian Feldman thank you for providing some background on the direction of the internal notes feature. I'm also in the "please keep them!!" camp! In our workplace we've loved using Halp for 3+ years, now across ~15 request channels, and have private notes as default. 

As @Ian Kyslytsya wrote above, private notes in the Assist/Halp ecosystem, given their integration with the Slack interface, are such an important component of its utility. Threads in Slack are inherently conversational, and the beauty of Assist for us was always the 2 dimensions of conversation - internal and customer-facing. Some long-lived ticket threads grow to 50+ messages from multiple involved parties, while only important customer-relevant information makes it back to them. Handing over tickets across support team rotations is seamless, context is surfaced easily and completely from Slack.

The :mega: megaphone emoji has become somewhat iconic for us, as an emblem of the awesome Assist product and what it means for us. It'll be a huge loss to its capability to kill in-thread private notes, and as others here have said, if Assist becomes a restricted mirror of the customer-facing hemisphere of JSM into Slack, for us I think we'd start to question why bother? It could be in the same channel.

[hayato yamazaki]

When I expressed my request to Atlassian's Japanese support team, they created a feature proposal ticket in English.

[JSDCLOUD-13674] ["Agent replies now default to public" change] Ability to keep option to defaulted to private for Slack Assist - Create and track feature requests for Atlassian products.

If you agree with the content, please vote!

@Joseph Whyle @Andrew Conley @Max Edwards 

[A Panait]

Just adding my voice to the ones above me. Stop removing options no one asks you to remove for invented reasons. Halp was loved for the features that you are slowly cutting every month or so. Using the lock emoji is such a useful feature for me and my team. Just leave us the option to enable or disable it if YOU don't care about it. 

[Andy Conley]

@Brian Feldman @Marie Casabonne 

Can either of you address this question out of my post above? This is a critical factor in how my company is going to proceed.

• Support for Third-Party Marketplace Add-ons: Can Atlassian confirm continued support for third-party marketplace add-ons that enable us to modify the default visibility of comments? This support is crucial for maintaining flexibility and control over our customer communications.

[Tom Murphy]

Seriously you guys just keep changing things and claiming it's for the better... 🔒 in a message was such a great feature when youre in slack having a chat with someone and you need to quickly take an internal note or flag something to a member of your team! 

You also got rid of the request participants updates in Slack which has been a serious issue. We're paying for Premium but you're taking away all the features that make Assist useful to Slack. So disappointing.  

Please bring back the request participant notifications as an optional feature atleast for organisations - https://jira.atlassian.com/browse/JSDCLOUD-13188

[Marie Casabonne]

Hi @Andrew Conley - to reply to your question about third-party add-ons, Assist does not control or have an impact on the third party marketplace add-ons you may be using with Jira Service Management. If an agent reply is added as a public vs internal note in Jira Service Management, Assist will respect that comment's visibility (public or internal) in Slack in the format it receives it from Jira Service Management.

The change we're making is to end support for a Halp-only global configuration that controls default agent reply in agent channels in Slack. The default agent reply in Jira Service Management is public replies. There is no setting today in Jira Service Management to alter that default to internal notes, so Assist, now as a part of Jira Service Management, is aligning more directly with this configuration.

[hayato yamazaki]

@Marie Casabonne 

In the first place, why would messages posted on agent channels that recommend private channels be treated as "public"?

The agent channel is used not only to operate Jira issues, but also to list comments registered to issues.

Considering the characteristics of Slack, which is a messaging tool, it seems best to ensure that comments can be viewed at a glance.

Regardless of whether comments are public or private, the visibility of comments should be maintained.

Also, it seems like Slack's design concept of "private" is being ignored, but what are your thoughts on that?

[Manuel]

THANKS AGAIN ATLASSIAN FOR SCREWING EVERYTHING UP FOR US WITHOUT NOTIFYING US.

I take it you love breaking the great things you had for your customers without telling them, nor realizing that these are what made Halp a great product.

[Tiffany Woods]

It would have been really nice to know some of these things via direct communication, not having to hunt down an Atlassian article after our company's ticketing system disappeared from Slack's Atlassian Assist at 1PM on a Friday.