Atlassian Team members are employees working across the company in a wide variety of roles.
October 17, 2023 edited
@Michael Young thanks for sharing! I'd like to better understand which part of the current behavior is introducing the most friction.
The current "private ticket" experience should remain nearly identical to how it was before. Once the ticket goes private, any comments added to the ticket will be between only the Agent's thread and the Requester in a DM with Assist. Any comments added to the public thread will not be track/synced to the ticket.
The main delta between the experiences is the following:
Previously: If someone attempts to add a comment onto the previously public thread, Assist will not sync it to the ticket. Assist would also delete that user's comment from the public Slack thread.
New experience: If someone attempts to add a comment onto the previously public thread, Assist will not sync it to the ticket.
So the main difference is that Assist no longer deletes user comments added to the public thread. This is a step towards reducing the amount of sensitive scopes customers need to grant Assist, where Assist would not require the ability to delete user's comment in order to operate.
To confirm, is the above experience what you are seeing? Or are you getting something else? (I just want to rule out any bugs)
If you are getting the above, then it sounds like the main pain point is maybe that users are continuing to post comments into public thread. And because the deleting is not occurring, they aren't being effectively dissuaded from that surface. Is this an accurate reflection of what you're experiencing?
@Ryan Pigeon apologies, I'm not fully understanding the issue. Can you describe a bit more about your specific scenario? It sounds like you are also trying to use the Private chat requests setting, and there is an inconsistency where sometimes the requests are still appearing in the public channel. Is that correct or am I misinterpreting?
@Brian Feldman -- Please bring back the filter/lists in the assist app. It's literally the one thing that doesn't make sense and has myself and my clients that i pushed JSM/assist to, steamed. How can anyone think that this "home" layout is MORE helpful, than the old filters/lists view? It was so easy to see what tickets were open/in progress for agents, and requesters :(. Leaving slack and clicking the view your requests is very clunky and so counterproductive compared to how it was. It was literally perfect.
In the need that someone needed to pull back an old ticket or you were an agent with 100's of past closed tickets, then going to the browser / website makes sense, but it's nice to see what tickets you have open as an agent assigned to you.
I'm just curious from the crew, on why they feel this change is beneficial? I would love to have solutions improved upon and i'm all for change, as long as practical things aren't removed, or changed to a point that makes them broken or useless.
Once we turn on the Private chat Requests setting, issues submitted into our request channel in slack will not sync any messages to the triage channel or from the triage channel to the original request thread.
If we leave Private Chat Requests turned off, then it functions as it did previously. The issue we run into is an issue submitted by a user through the /halp command or through the Assist application will populate within the triage channel AND in the Request channel as this is different from the previous behaviors.
So in any event, the ideal functionality we previously had will not work and I am looking for a solution that would give us the original functionality, or what the best practices would be going forward.
Thanks for the response. Everything is working as you would expect. You hit the nail on the head. The main pain point is that comments are still being posted into the public thread once an issue has been created on Jira. The prior behavior of deleting the comment encouraged the user to use the Assist app or go to the ticket on the Portal.
Please return messages to Slack for participants or let us choose deliver or not messages to them. Without this functionality, integration with Slack makes no sense. Hear feedback from all customers.
Alot of useful features being obliterated by Atlassian, forget about ticket, pushpins and filtering tickets in assist (I don't know why Atlassian think it is necessary to take away), I feel more destructions coming with Atlassian takeover on Halp which was perfectly fine and how disappointing, look at all these comments, they 've just literally turned the most useful features into nightmares. Anyone calling those shots should be held accountable and very poorly executed! Our users and clients are no longer able to use ticket emoji to create issues which we like it very much. But now, admins got to backfill all the requests, issues and typing in manually in Raise Form, and We are not going to deal with this anymore, we are out!!
Using the ticket Emoji for private DMs was very convenient for me. I understand that tickets can accidentally be raised but you completely turned off that feature and now only the ticket emoji can be used in Request Channels which inconveniences both my users and myself. I would like to continue using assist but I would like to use it so I can add a ticket emoji to a private DM and have that ticket automatically created for me in the Request Channel.
Can we at least have an option to enable / disable this feature? This feature saved agents so much time and and saved the company money. Now we have to create the ticket manually or direct our user to open the ticket themselves instead of just simply pushing the ticket emoji button and having the ticket automatically created and it is time consuming. It was an impressive feature that always left the user in awe and now we have to direct them to open a ticket the old-school way. Freshdesk did the same thing and took away this convenient solution and thats why i switched to Atlassian but at least give us an option to turn it on or off - pretty please - with a cherry on top!!
Atlassian Team members are employees working across the company in a wide variety of roles.
October 24, 2023 edited
Hi @Andrew Kazinec@Zayar@Matt Saltzman , I totally understand the ease and simplicity of using the ticket emoji is one of the best parts of Assist! So any adjustments or limitations to it are immediately noticeable -- I apologize for that!
As a step towards delivering a safer and more secure experience, we've made this shift to ensure that Assist is only taking action on global emojis while inside of explicitly configured Request channels.
You should however still be able to trigger the same 2-click ticket creation flow via DMs and non-configured channels. In a DM for example, you should still be able to create tickets out of messages by:
Hover over the message, click the 3 dots
Select Raise a request with Atlassian Assist
This should result in the same experience the ticket emoji would have previously triggered, both with just 2-clicks. I wanted to check if you are at least seeing that, or if that functionality is missing for you?
Hi Brian and thank you for your response. We have the functionality and it is very useful but it just adds extra steps to our day-to-day. The ticket Emoji was a one-stop one-click solution and perfect for creating those on the fly tickets.
It would be preferable if we can at least have the option of turning the feature on or off and let us customers decide to have a safer and more secure experience in our own environment, instead of making a global change for everyone and not giving them the option to use it at all.
Any comments on removing the list from the app and adding 4x more steps and having to leave Slack to view your open tickets/requests?? Really curious how someone thought this was better. Seems like atlassian just wants to dodge this question about why it was removed.
This one still has me facepalming each morning and heated clients of mine that i recommended assist/jira too (both for internal ticketing with requesters and agents, and for external, agents only using in slack).
I don't see a security issue with this one, and now the landing page for the assist app is basically useless other than an "make a request" button.... seems like wasted real estate and an incomplete products :-/
@[deleted] First and foremost, please don't apologize as it doesn't solve anything, the right thing to do is to reinstate what was working before and make it work again, I am pretty sure nobody in comment session has requested for this complication and you didn't answer why the need to remove those. So please don't apologize.
Secondly, you wanna argue about secure experience? Sure! This step JIRA taking is delivering a safer and more secure experience? Can you provide me a logic how does it more secure and safer by restricting global emojis action to a public request channel? How does it make insecure and unsafe by allowing global emojis to DM and private chat?
Now here are real life problems, we did have public request channels and it did not go so well. I have users and clients reaching out to me and said that they don't like what they are working or requesting or what they are up to are publicly displaying as issues in request channel! I can clearly see they are feeling INSECURE by raising request in a public request channel! So, nobody likes to make requests in a public channel, and it also create nuisance to other users too. Now that is the reason, we are using direct DM and convert to an issue with 1 click emoji, so clients don't have to worry about who can see what they are up to or what they are dealing with.
Finally, your two clicks solution doesn't work in my environment. Clicking on ... and raise a form, I got the screen below, and I have 2 triage-channels, which was working perfectly fine with ticket emoji to IT support and moneybag emoji to finance support and your solution doesn't work at all, we still got to raise a form, manually enter direct message request, select drop down and look for who is requestor, select drop down who will be assignee, etc. What it was supposed to be 1 second issue creation becomes 1 mins, 1 issue not a problem I can take 1 min to create for users/clients, 50 issues will you do that for 50mins?
@Zayar agreed. I'm wondering how it's MORE secure for someone to leave a SECURE SSO/SCIM slack session (aka the internal requester) to go view their open tickets in a list in the BROWSER now by having to leave the secure slack session and either create a new account that isn't SSO enabled, so it's now a rogue password/login that leaves our secure IDP/SSO session to goto the Jira browser JUST to view a list of their open tickets, so they can find it and reply in the browser instead of Slack? So now our conditional access policies and MFA aren't applying to this rogue JSM account for the requester, that had to be created. Makes a lot of sense and is super secure.... i just don't get it.
Hi @Brian Feldman, thank you for your message and support on this!
Responding to your question below: I am not having the same experience. Please help. Instead, after using the Raise a request feature, I have to manually copy and paste the lengthy troubleshooting conversation (I had/still having with the person who requested support) into the Description field of the prompt that appears. Not only is this (1) more cumbersome/more than 2 clicks but (2) it produces a sloppier/unorganized reference to all the vital info I've gathered from the user on the issue they were/are experiencing when compared to each Slack message being neatly converted to a comment and organized in the Activity > Comments section of the Jira ticket before these unexpected changes were made. The notes from these conversations with users is one of the few resources I have to understand and resolve recurring issues. They are precious. Having them organized at a high level so they serve as the best reference possible is absolutely essential.
This should result in the same experience the ticket emoji would have previously triggered, both with just 2-clicks. I wanted to check if you are at least seeing that, or if that functionality is missing for you?
Additionally, my org has a channel dedicated to tech support and I encourage people to use it regularly but as Zayar pointed out often times people feel more comfortable messaging me directly for support (and I don't blame them).
Re:
"...step towards delivering a safer and more secure experience."
and
"...reduces the number of scopes Assist needs access to in Slack to function, making your data more secure."
As Matt Saltzman already suggested, at least provide options. As the IT admin I regularly have to make org-wide decisions/changes with security in mind. This would be nothing new. Thanks for reading!
I don't know if this has already been answered but is there a way to create the ticket through Slack and have the message go into the description so we only have to write a short summary? It doesn't make sense to have the message, which may be long, go into the summary.
Atlassian Team members are employees working across the company in a wide variety of roles.
October 27, 2023 edited
@Michael Young Gotcha, thanks! We're looking into some tweaks that might serve as a stronger deterrent for users continuing to post into the public/unsynced thread!
@Shalabh Chaudhri yes, slash commands should continue to work! Could it be that the user is a member of the other workspace where Assist is not installed? In which case Slack would not recognize the slash command from workspace.
@Andrew Kazinec are you referring to using a message action in DMs? If so, similar to how ticket emoji used to work (and continues to work in request channels), the original message should be auto-pasted into the "Title/Summary" field for the request. It sounds like that's not happening for you, is that correct? If so, could you reach out to our support team for troubleshooting? Or let me know if I'm misinterpreting!
I'm not sure how the change to Assist notifications is effective when it doesn't notify me that a request where I'm a participant even exists. I'm sorry, but what's the purpose of having the Assist app for Slack if we're made to go through the emails?
If someone is bothered by notifications and wants to go through email, they should remove their Assist then or you can add the option for the users to opt in or out of notifications.
The notifications should notify the participant that they've been added to a thread and also whenever they are mentioned. This way I am made to "discover" that I've been added as a participant by checking my email inbox. Defeats the purpose of Assist, doesn't it?
I'm kinda shocked, is there any possibility to return old version of assist?(
And i'm really need community help "how to set up at least notification when someone mentioning users from Request participants → to Assist?" Mb any workaround?>
@Tymur Mercy agreed on the notification for mentioning user from request participants. This is a huge loss for us both on the admin/agent side being cc'd via automation making them a request participant when the other agent "takes" the ticket, plus additional users being added to the ticket via assist/slack.
The decision not to notify request participants about a request conversation they're on in Slack unless they comment on the thread shows a clear misunderstanding about Slack and its usage. A Slack ticket should operate the same way a slack thread does, as the experience to the end user is effectively the same. It is a thread, it behaves like a thread, and the users (both agents and customers) are going to expect it to behave like a thread.
All participants (reporter, assignee, participants) should see the conversation and receive notifications and messages for non-internal note comments.
This decision needs to be reversed, or at minimum a setting added that allow an JSM admin to configure whether or not request participants should receive notifications via Assist.
@Jacob Waters i couldn't agree more. Slack should work like Slack and there isn't an understanding nor major focus on the Slack experience. This shows that JSM took OVER Assist/Halp and not the other way around and it's obvious.
Assist/HALP Pre-JSM was ALL about the Slack experience, but JSM's takeover has reversed and taken away all that made Assist/HALP special. If JSM left the Assist/HALP experience as it was but added the advanced JSM functionalities (automations, etc), it would be a homerun.
There are reasons many IT admin's did NOT goto JSM when implementing a ticketing system for their environment or Client's environments. What is the main reason? Assist/Halp existed and was SIMPLE, and ahead of it's time, as well as disrupting the typical boring ticketing systems out there. The main plus was that it was 2 way communication RIGHT INSIDE OF SLACK and it just worked...
Adoption rate for my main Assist/Halp environment/company as well as my customers/clients was near instant and near 100%... and these are companies that did NOT ever have a Ticketing system and a traditional email ticketing system just wouldn't have had the adoption that the Slack Ticketing system had.
64 comments