I agree with the general sentiment that this update was a giant step backwards. In addition to all the aforementioned reasons this has greatly diminished the usability of Halp/Chat, we've encountered a new behavior that's equally bad. I'm not sure if it's part of this update, another one, or what - as I haven't yet read about this change: Since there's no way for customers to choose to subscribe to all JSM updates in Slack (which would be a great feature to have), we setup the helpdesk JSM project to have a single request type that is linked to Slack. All the other request types are JSM only. This way if a user creates their ticket in Slack, they get all future updates in Slack - but if they created their issue via email or the portal, they don't get the updates in Slack - which some users find too noisy. Not a perfect solution, but it worked. In the past few weeks it seems this is no longer possible, because the SOP for helpdesk is to move all tickets to their correct categorization, and the request type that is linked to Slack is a generic/uncategorized request type that serves as a catch-all before it's triaged into the correct request type. Now when helpdesk moves the ticket to the proper request type, it unlinks the ticket from Slack with the following message:
Atlassian Assist 20 hours ago This request is no longer connected to Slack, so you can't interact with it here. For updates, go to the request.
So, again, it breaks the expected behavior. Our employees have an expectation, that if they can start the communications of a ticket in Slack, they should stay there. It's not like the tickets are even being moved to another project, they're staying in the original project - which is linked to Slack - we're just changing the request type. I was originally excited when I saw that Halp was being fully integrated with JSM as Chat, but every update since this has happened has been a giant leap backwards. I've already contacted support & put in multiple feature requests to try and get back the very useful features that Atlassian keeps removing from this product.
In chat settings, you can connect additional request types via the Request Types tab. Only the ones listed there can remain synced within Slack. If an existing chat request were to transitioned to a request type that is not added there, it will result in the experience you are referencing.
Recommendation: It sounds like your goal is to restrict the request types that requesters are allowed to initiate, but you still want additional request types to remain syncing in Slack in the change that the request is moved to another type. Is that correct?
If so, first add the additional request types to the Request Types tab in chat settings -- this will ensure that the request can continue syncing in Slack. Second, edit which request types are available to requesters in your request channel by filtering out the additional types -- this will ensure that requesters are only able to initiate request with the types you have explicitly associated to the request channel. Hope this helps!
@Brian Feldman - this worked previously. And I have already opened a ticket. PCS-232231 This behavior changed between November 6th and November 8th.
If I do what you said, I believe that tickets in all the request types will automatically sync to Slack, even if initiated via email or portal. This isn't what we want. We want it to work the way it was previously. And, even better, the way it worked before Atlassian started removing all the features that were part of Halp.
Why would you remove one of the best features of Halp, creating tickets from DMs or any public channel via the :ticket: emoji? It was there because users like to message agents or anyone from the support team directly instead of the support channel or raise a ticket themselves. What's the point of having it work only in some channels? Please bring it back, this doesn't make any sense!!!
I would like to add to this. I went with Halp for the same reasons that most of the people did. I could keep things in Slack, communicate with my employees, and use Slack for approval process by CC'ing managers as participants for quick approvals. We even started automating our onboarding and offboarding processes using these features with Jira SM and Assist making it perfect for auditing and communications.
I just discovered this issue today as our requested participants are no longer receiving Slack notifications. This is causing major issues as NO ONE USES EMAIL FOR THESE THINGS ANYMORE. Email is slow, and with all the crap out there messages are missed. We moved away from the Jira Portal as well because there was no need for it. Slack and Halp provided exactly what we needed, and a much better experience for everyone involved.
Sorry Atlassian, but whoever approved these changes should be fired. They have no idea or understanding how business are evolving and working in today's world. Might be time to abandon Jira SM as well.
@Manuel Couldn't agree more. There is a reason myself and my clients started in HALP/Assist instead of competitors that have been around for awhile that were stuck in the past using email only. Slack/Teams is the future and the reason why HALP/Assist was so popular.
Not sure why Atlassian / Jira purchased/merged with HALP/Assist if they were only going to not use it for what made it special in the first place. Was it just to squash the competition? if so there are many other platforms out there copying the HALP/Assist model.
@Joseph this is a huge peeve of mine. We can't even add them and then @mention them in the thread/ticket. They don't receive ANY notifications in slack and don't see it in assist messages tab nor is it in the threads / activity area of slack anymore. This is beyond ridiculous and frustrating.
Aren't mergers and updates supposed to plus a product not make it practically useless... smh.
@Brian Feldman replying to your October support message: HNY!
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!
Yes, I am referring to the message action in DMs and yes, you are misinterpreting. The original single-line message is auto-pasted into the "Title/Summary" field for the request as expected. No issue there.
The issue is with all the lines/messages AFTER the original message. (I'm at risk of repeating myself but) these troubleshooting conversations can be 100 lines of text including vital screenshots within the context of the conversation. With the previous pushpin emoji functionality, the entire conversation, beginning to end, including any images shared between me and the end user could be easily and seamlessly synced/copied right to the ticket and organized and formatted perfectly in the comments section.
After the changes announced here, the only recourse I'm aware of is copying the convo from Slack and pasting it into the ticket. This is disruptive and problematic because:
The text formatting doesn't carry over into the ticket and ends up being very messy because of the lack of formatting, Slack timestamps, user statuses, emojis and avatars that end up mixed in with the messages. You can easily replicate this unwanted result on your own by selecting, copying and pasting a few lines of a Slack conversation into any notes app. It's unorganized and unhelpful. Please help.
The images/screenshots don't transfer when pasting. They help me and my team resolve recurring issues even faster the next time they may arise. Instead, after these changes, I have to download each screenshot, leave Slack, open Jira, find the ticket, find the part of the convo where the image is relevant, then tediously drop them into the ticket. I simply cannot do this as I have to move onto the next support request. These screenshots or photos of the issue I'm helping resolve are absolutely vital to the resolution and without them make for a poorer service mgmt product.
Less importantly, there is a character limit to how many characters you can paste into the description field in the Assist app RAR prompt. So if the conversation length exceeds that character limit, I have to proceed without it, leave Slack, open Jira, find the new ticket, then paste it etc etc. Whereas before, I did not have to leave Slack and I could move onto the next support request. Although, raising this limit would not resolve the more important issues above.
If this is still not clear via these messages, I'm happy to connect on a video call.
We recently came to learn that Atlassian has made the following change to Atlassian Assists functionality in Slack.
Main issue: As a part of this change, request participants will only receive request updates by email, unless they comment on the request thread in Slack.
We relied on this feature for private requests. For example if someone makes a private request that doesn't go into a public channel, we could add them as a request participant and Assist would DM all those added and share the ticket and thread with them. This allowed them to answer and give context on tickets when needed.
I'm baffled as to why this was just removed, and instead you didn't just make it an option for an organisation to enable to disable it. We love JSM, but prefer for employees to use it as a Slack first solution and our agents are the ones who benefit from the Jira dashboards and UI etc.
This new update means when I add a request participant I need to be confident that they're actively checking their emails and they need to reply to the email to comment. We desperately need the feature back so that it notifies them in Slack and allows them to easily track and comment again.
We recently have/are making the update to Premium and this feature was a major selling point for what we are trying to build.
Is there anything we can do, given you had this feature in the past so must have the code somewhere, to adapt this to make it optional for organisation and not just disable it for all.
Unfortunately Jira has locked down API access for third parties to be able to perform the same tasks, so no, there is not another product. I actually work closely with another company that provides a great solution for Slack integrations with Support Apps, however Jira will not work with them when they looked into it because of this reason. I think we are all stuck unless we get off of Jira.
Also, they've seemed to make more changes and things are not working for other things now. I'm so tired of them making changes for no reason. For the amount of money people pay for this, it's sad that they don't really listen to their customer base.
@Manuel couldn't agree more. It's like they are trying to keep the dev team(s) busy to stay relevant while making the product irrelevant.....
The shotgunning to remove features and lack of care and ear to their customer base that actually uses these products is a red flag for sure.. it's been crickets for over half a year lol.
@Manuel I'm totally not fussed about Jira – we were very happy using the web-based backend of Halp where needed, but mainly we did everything in Slack (which was part of the joy of Halp).
64 comments