Creating a more cohesive Assist experience in Slack

[Marie Casabonne]

Hi everyone,

Thank you to all those who have provided helpful feedback on these changes to the Assist user experience in Slack. I wanted to call out one significant change that is noted at the top of the blog post and in the main body below.

We’ve decided to keep the lock emoji () functionality for adding internal notes on tickets from agent channels in Slack. We understand how crucial this functionality is for keeping agents in the flow of the conversation and triaging issues collaboratively from Slack.We do still 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.

Tagging the folks who provided feedback on this change for visibility - @Tom Murphy , @A Panait, @Ian Kyslytsya  

[hayato yamazaki]

Thank you for listening to the voices of enthusiastic JSM users. @Marie Casabonne 

Is the default treatment of messages in agent channels public? Or can I choose to make it private?

While the lock emoji is important, it's equally important that messages in the private agent channel remain private.

[A Panait]

Thank you for your understanding and for listening to the community @Marie Casabonne 

[Andy Conley]

Thank you, @Marie Casabonne

[Marie Casabonne]

Hi @hayato yamazaki - the default agent reply configuration (that is today, only available migrated Halp customers and can only be configurable in Halp) is still being removed. Starting on March in 27th, agent replies from agent channels will default to public, and agents will need to use the lock emoji (🔒) to add private comments from agent channels. 

Last week on Feb 29, we started sending whisper Slack messages to agents when they add comments via the agent channel to tell them that their comments will soon default to public. We also remind them to use the lock emoji to send private comments.

The shift for agents with this change is that instead of using an emoji to denote a public comment - the mega emoji (📣) - agents will need to use an emoji to denote a private comment - the lock emoji (🔒).

[Greg Smith]

@Marie Casabonne @Brian Feldman 

Can we get back the ability to add Request Participants to the Assist thread? Our approvers are added as Request Participants, and by not having this ability, you've set up two different communication channels for all tickets needing approvals. Agents and requesters can talk on Slack via their threads, but approvers still have to go into their email, click the link and comment via the web portal. Request Participants are not pinged on Slack when the ticket is updated either, even though they are very much part of this process.

Conversations regarding approvals often happen between all three parties: request participants, agents, and requesters. And you've locked one of these people out. 

[Brian Feldman]

Hi @Greg Smith -- we are exploring ways to reintroduce notifications for Request Participants in JSM chat. Here's an associated ticket where we'll be sharing updates: https://jira.atlassian.com/browse/JSDCLOUD-13188

[hayato yamazaki]

Thank you for your reply. I've been waiting for your comment for a long time.

@Marie Casabonne 

We are aware of internal comments that began late last month and Slack message reminders related to behavioral changes that began in March.

Are you aware of any issues with the specification that treats agent channel messages as public comments?

Agent channels are configured as private channels.

Set up chat in Slack | Jira Service Management Cloud | Atlassian Support

An agent channel is a private channel within your Slack workspace

The official documentation also says so.

This means that messages posted to the agent channel are private.

That's the basic understanding of Slack users.

However, we recognize that it is necessary to distinguish between private and public posted messages, taking into consideration the relationship with the JSM we collaborate with and the nature of the content.

On the other hand, in Slack, it is an absolute specification that messages in private channels are treated as private.

It cannot be denied that ignoring this specification and treating private messages as "public" will create inconsistencies in the specifications, pose risks, and cause problems in the future.

The issue of publishing messages that shouldn't be made public is already becoming apparent.

That happens simply because you don't use 🔓 :lock: emoji.

Don't you think it's important to correctly understand the characteristics of the tool "Slack" that work together and design the specifications to avoid misunderstandings?

I hope you make the right decision.

cf. [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.

Below are additional comments,

It's okay for agents to be able to see all messages in the triage-agent channel. However, the problem is that messages without 🔓 :lock: emoji in the agent channel are copied to the request channel, where anyone can see them.

My understanding is that only messages in the agent channel that are explicitly marked with  :mega: should be copied to the request channel.

This is because messages in private channels are generally treated as private.

It doesn't matter whether your first message when somebody raise a ticket is published or not.

Comments in a thread should be freely controllable as public or private. However, I want messages in private channel threads to remain private by default.

Am I able to express my intent well?

[Jarid Spokes]

I find it disappointing that Atlassian are removing the "Private first" behaviour of comments within the agent channel. It is going to make conversation flow much harder for our use case, where we often have long conversations around potential solutions and options for our customer before providing an update using the :mega: emoji.

I can see this ending up with comments that are intended to be private accidentally being sent as a public reply on the non-agent channel.

[hayato yamazaki]

Will there be any updates on handling after that? @Marie Casabonne 

The number of votes for related request tickets has risen to the top 3, so I think other users are also very interested.

[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.

[hayato yamazaki]

So you have finally released it with the exact opposite specifications. @Marie Casabonne 

Why didn't you understand that this change of yours would put us at a disadvantage in our operations?

It's very disappointing and very sad.

Judging from the number of votes for the tickets posted below, I think many users are disappointed.

[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.

There is a difference between disclosing information needlessly and providing information correctly.

We hope that an appropriate review will be carried out in the near future.

[Serhii Vdovenko]

Is there a roadmap somewhere on the planned features for Assist?
We have a lot of Request Types that use Forms now.
Assist does not currently support Forms. I would like to understand if we should change Request Types or we could wait for new features

[Rick Martínez]

I am mystified by the notion that it could be considered a good idea to have a public support Slack channel and a private agent Slack channel where replies to a thread representing the ticket in the private agent Slack channel would default to syncing it publicly to the ticket and to the public support Slack channel. I've read the posts here and I can't figure out for the life of me how that actually solves a problem?

Now I'm going to have to kick my agents out of the private channel to prevent them from accidentally having a private discussion that then gets inadvertently synced to the issue requestor 😂

[Majken Longlade]

@Marie Casabonne  Just catching up on my community threads. I'm glad to see the lock emoji isn't going away, but I would absolutely want the button option for a few use cases where people who don't work tickets often still need agent access.