Atlassian Team members are employees working across the company in a wide variety of roles.
March 4, 2024 edited
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.
Atlassian Team members are employees working across the company in a wide variety of roles.
March 5, 2024 edited
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 (🔒).
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.
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?
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.
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.
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
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 😂
@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.
39 comments