Upcoming changes to Atlassian Assist in Slack

[#1]

Update: Due to a holiday in our US offices, we've moved the release date for these updates to October 11.

Hi there

I'm Marie and I'm a product manager for Jira Service Management.

Earlier this year, we decided to include Halp’s conversational ticketing features exclusively in Jira Service Management Cloud. Now, we’re making the Atlassian Assist experience in Slack more secure and efficient by introducing a few changes. We’re also removing legacy Halp features that duplicate experiences in Jira Service Management.

This blog exclusively outlines changes to the Assist and Slack integration — we plan to make improvements to the Microsoft Teams experience in the coming months. We’ll make a separate post when it’s time to announce updates to Teams.

These changes go into effect on October 5, 2023. Here’s a preview of what to expect so you can prepare your teams.

Updated app home interface

What is it? We’ve revamped Assist’s app home to better support the requester experience. Previously, people who were both agents and requesters had a confusing experience in app home, since it displayed both the requests they’ve raised and the issues they work on as agents.

Anyone can visit app home to get a quick understanding of how to use Assist, discover where they can ask for help, and go to the help center to see existing requests and support documentation. To streamline the experience, we’re removing the request/issue list, so requesters need to view their open requests from the help center. Agents can view their assigned issues in their queues in Jira Service Management.

What should I do to prepare? If your agents frequently use app home to view their open issues, let them know this change is coming. They can continue to use agent channels to respond to, change status, and triage issues.

Updated request and issue display

What is it? Requests and issues have a new look in Slack. This new display uses Slack’s block kit, so it’s more responsive and accessible. We’ve also updated what information shows based on what requesters and agents need and use — you can now see status, request type, requester, and assignee at a glance.

What should I do to prepare? Let your agents know some visual changes are coming, but overall functionality remains the same.

Updated bot notifications

What is it? We heard your feedback that Assist notifications create noise for agents and requesters. Assist still adds a comment to the thread, and it will now also at-mention the requester or the assigned agent to subscribe them to thread notifications. This means all interactions happen in one place: on the request/issue thread.

As a part of this change, request participants will only receive request updates by email, unless they comment on the request thread in Slack.

Admins can no longer customize the bot messages sent by Assist. You can still turn these messages on or off as needed.

What should I do to prepare? If you have customized bot messages, we recommend saving a copy of the content in case you want to reference it in the future.

Updated ticket emoji experience

What is it? We all know and love the ticket emoji — it’s a quick and easy way to raise a request, and it’s not going anywhere! For consistency, and to prevent Assist from accidentally raising requests in conversations it’s not invited to, the ticket emoji now only functions in configured request channels.

If your agents need to raise a request in a direct message or a channel that Assist isn’t invited to, they can use the More actions menu.

What should I do to prepare? If your agents frequently use the ticket emoji to raise requests in direct messages or in non-configured channels, let them know they need to use the More actions menu instead.

Updated slash commands

What is it? Similar to our app home makeover, we’re removing agent-only slash commands to optimize for the requester experience. Using the /assist command (or /halp, /helpdesk, or /support) now prompts request creation, rather than revealing hidden agent commands like viewing or searching through open issues.

For everyone using the /assist command to raise a request in a request channel, the request now posts in that channel rather than in the private Assist DM. If your project uses private chat requests (more on that below!), though, the request will remain in private DMs.

What should I do to prepare? If your team often uses these commands to see a list of their assigned issues, encourage them to use their queue views in their web browser. Alternatively, you can use Jira automation to automatically post open issues to Slack.

Private updates are now private chat requests

What is it? We’ve changed the name for private updates to more accurately represent what the setting is, as it allows for private requests through Slack. We’re also adjusting the experience — any comments posted on the request channel thread will remain, but they won’t sync with the issue in Jira.

Note: This doesn’t change the experience for public requests (projects that don’t have private chat requests enabled). Thread comments across agent and request channels will continue to sync.

This reduces the number of scopes Assist needs access to in Slack to function, making your data more secure.

What should I do to prepare? Let your agents know of this behavior change, and remind them not to post on private chat request channel threads.

New: Hidden projects during issue creation

What is it? We’re introducing a new setting so you can better control where requests are raised. By turning on Hide project during issue creation from your project’s settings, you can ensure that requests are only raised from the explicitly configured request channels. If this setting is turned on, requesters can’t raise requests for this project from app home or using the slack command.

What should I do to prepare? This setting is helpful for testing or more sensitive projects — like human resources or legal topics. If this sounds like any projects your company has, or if you’ve been wanting a less disruptive way to test new request types and projects in Slack, get ready to turn this setting on once released.

Removing the pushpin emoji functionality

What is it? We made the decision to deprecate a little-known legacy feature — the use of the pushpin and ticket emojis to raise a request from multiple messages. By removing this functionality, we can reduce the number of Slack scopes Assist needs to function.

What should I do to prepare? If your team uses this functionality frequently, let them know they can still raise requests using the ticket emoji. To add more context to a request, simply comment on the thread and the comments sync with the Jira issue.

That’s it for now, but please feel free to ask questions or leave feedback in the comments below!

[Ian Kyslytsya]

Regarding the bot notifications, do I understand correctly that we will be no longer able to have automated bot messages sent to the agent and requester channels when an issue is created? If that is the case, why are you removing this feature? We are using it and like it very much. 

Regarding the comments in the thread syncing with the Jira issue. Do I understand correctly that comments made in the thread of the issue in slack in the request channel (and in parallel in the agent channel) made by both agents and requesters won’t be synced with the Jira issue? If that is the case, why are you removing this feature? This is literally the point of the integration, to sync ticket notes/comments made in Slack with the respective Jira issue. 

[Andy]

The pushpin feature was fantastic! Does that mean there's any traction on JSDCLOUD-12760? We've switched over to the VA creating tickets for our users, but some users still like to post 5 messages in a row in Slack - the ability to combine them, whether manually or, even better, automatically, greatly streamlines the process. 

[Sarah Fornander]

Will there be knowledge base implementation into the slack bot before the June cutoff date? Or, are halp Answers users being forced to upgrade to the virtual agent solution to continue deflecting questions in slack?

[Mike Solomon]

@Ian Kyslytsya I too like the automated bot message -- if it gets removed, hopefully we can use automation to achieve something similar.

@Marie Casabonne I share Ian's desire for more clarity around this statement: 

> all interactions happen in one place: on the request/issue thread.

I was confused by this statement because I am unsure about how this is different than how the integration operates today. Ian's interpretation was that there is no longer a sync between the slack thread and Jira comments. If that's the case, that's a huge change and it would take away the biggest value-add of the integration IMO. How would private chats happen if this was the case?

Can you please provide more clarity about what that means?

[Majken Longlade]

Agreed on the pushpin, it's a great feature and IMO the solution here is marketing, not ripping it out. 

I also found some of the updates unclear.  eg: "We’ve also updated what information shows based on what requesters and agents need and use." I don't know what that means in practice, more details on what will be shown, or how it's decided what is needed or used would be helpful.

The hidden projects feature I think also needs the explanation fleshed out. I'm guessing this means the project would not be listed when you use the create button in Jira, but it will be available from the customer portal or Slack? 

[Monica Rutherford]

Agreeing with everyone else, if threads are no longer going to sync that's a huge loss of functionality. Could you provide more clarity on this change?

[Ricky Jordan]

Who's running things over there at Jira?  Where do i start?  And with less than a month for large DRASTIC changes that might deter our slack only internal requester users from using our ticketing system?  Who schedules these items and comes up with the timelines? maybe have your users vote onto the changes/features, and make sure those are the assist users and not jira browser only users.  

Having the assist app view for a list of all of the filtered requests that you are assigned to as an agent, or as a requester, is VITAL.  The slack app was there during halp/assist pre jira times so we DONT have to leave the Slack environment.  That was the whole point of using Halp, was it kept everything in slack for our requesters.  They DONT want to goto a help center, or navigate away from Slack. 

Also, we add participants/followers (aka slack users) to tickets so they can be CC'd on these tickets.  Example is maybe i have an assistant in training in the tech dept, so all tickets that i accept, add them as a follower so they get notifications in slack when someone replies in the ticket/thread, or vice versa when they accept the ticket, then i'm cc'd on it as a follower and get slack notifications.  Same with adding a manager as a follower, so they can sign off and approve something, etc if needed if their employee makes a request.

Many of these changes are taking away the IMPORTANT things that made assist and halp great, and taking it back to old legacy outdated help ticketing systems that are all email and browser based which is NOT where the trends are going?

Stop forcing things on us that we didn't ask for....

Oh, and please fix the display name updates in the slack assist app.  If someone's display name changes, unfortunately it doesn't update in the assist app and the team behind that fix has quoted many times, it's not important.

[Marie Casabonne]

Hi folks, thank you for your comments. I've updated the blog to clarify a few themes I saw throughout the comments, and have added some additional details and clarifications below on those core themes. If you have additional questions, please keep asking!

Comment syncing

There are no changes coming to comment syncing — comments on requests will continue to sync between Slack and Jira Service Management as they do today.

The one place there is a minor change to comments is related to when the Private chat requests (FKA private updates) feature is enabled. Read on in the next section for details on that change.

Private chat requests

Today, when private chat requests is enabled and a request is raised from a request channel, Assist does the following:

• Posts a message to the Slack thread in the request channel saying a private request was raised
• Sends the request to the help seeker via the Assist app
• Continues to monitor the original request channel thread that the private ticket was raised from, and delete any comments added to that thread.

The change we’re introducing to this feature is that Assist will no longer delete messages posted to the original thread.

Bot messages

Assist sends notifications on requests in two formats and to two different locations today. 

• Bot messages are sent as threaded messages to the requester and agent request threads in Slack when a request is created
• App notifications are sent as individual Assist app notifications to request contributors when a comment is added (until the user engages in the Slack thread), when an agent is assigned, and when a request is closed.

This introduces a lot of noise in Slack, and inconsistency in how Assist communicates with help seekers and agents. With these upcoming changes, we’re consolidating where we send bot notifications to one place and giving you control over which notifications to send or not send. 

Here’s what you can expect from the changes:

• All bot notifications will be sent to the request thread (requester sider) or issue thread (agent side) in Slack, depending on the type of notification
• You will be able to enable / disable all bot notifications
• The message text in the bot notifications will not be customizable (this is the biggest change to bot notifications)
• Instead of two bot notifications, Assist will now have five bot notifications

Agent notifications include:

• When an issue is created
• When an agent is assigned - this message will at-mention the assigned agent to bring them into the Slack thread
• When an issue is closed by another agent

 Requester notifications include:

• When a request is raised - this message will at-mention the requester to bring them into the Slack thread
• When a request is closed - this prompts the requester to see the CSAT whisper from Assist

These changes give you greater control over all the individual notifications Assist sends to your agents and requesters and unifies where Assist notifies everyone - in the ticket’s Slack thread itself, vs in both the ticket thread and the Assist app.

If you do want to send custom messages, we recommend using Jira Automations.

Hidden projects

This feature allows you to connect a Jira Service Management project to Slack without immediately making that project (and its connected request types) visible and accessible to help seekers via Assist app home (when they click ‘raise a request’) or when using slash commands to raise a request.

The project and its connected request types will only be visible to help seekers in request channels that a project admin connects to the project in Slack.

Why we’re introducing this feature:

• To allow customers to connect new projects to Slack without those projects and their request types immediately being visible to help seekers
• To allow admins to limit the scope of access for a particular project to a subset of requesters (via a specific request channel)

Halp vs Jira Service Management customers

Atlassian Assist (the app) supports both Halp and Jira Service Management. For customers still using Halp with Atlassian Assist, there are only a few changes that will impact your team. The upcoming changes impacting Halp customers are outlined in this blog post.

[Ricky Jordan]

@Marie Casabonne 

Thanks for the clarification on those items.

One thing that seems totally counterproductive and wasn't clarified is not having a list of open tickets or filtering tickets in the assist app for the requester or the agent as they have been using before.  Now they are pointed to a website/browser via the help center button and have no way to see open tickets inside of the assist app in slack.

I can't stress how disappointing this is to companies that were on halp/assist BEFORE jira took over and started changing things.  Many companies including myself and 6+ of my customers, went with halp/assist because their company could run the whole thing via slack with minimal need to goto the web browser, unless you were an admin or an agent that needed to get more features or search older tickets, or change settings, etc.

For the requesters, many companies adoption rate of ticket submissions will go down as users do NOT want to leave slack to view their requests/tickets.

As mentioned, i'm not sure who thought that was a good idea to remove that from the slack app lol.....  None of us asked for that...  Now adding the option, i understand, but removing a feature that is widely used just doesn't make any sense.  This was a huge feature that made halp/assist stand out above zendesk and other competitors as those ended up looping people to goto a website/portal/help center which many users did NOT want to do if all could be done inside of Slack.

It's 2023, Slack/Teams is the home base for companies, and apps live inside of these platforms so users don't have to LEAVE or have multiple windows open, etc. --- We aren't asking for a new feature, we are asking to have the option to continue using a feature that WORKED for so long...   Having the help center button is fine if you want to force the browser, but don't get rid of the list in slack to quickly find the thread(s)/tickets for agents and requesters.

I'm just trying to picture it now.  Users are in slack, they want to view their open tickets in assist, they goto the assist app, then don't see their list, and then are confused and hopefully click help center, and then find their ticket and then click on it, and they are expecting to be able to answer it in slack or pop up the thread, but instead they are forced to use the browser now and are confused if they should use slack or goto the browser.  (confused yet?).   Sounds like running gmail webmail in a browser while you have gmail in your outlook desktop app.  Why?? lol...

[Phill Saldana-Bailey]

I'd like to echo the disappointment about losing pushpin functionality, it's useful for ensuring all relevant information is captured in the ticket and removing it is a step backwards, you're creating more work for agents rather than making our lives easier. I hope, like with the ability to mark as done via an emoji, which briefly disappeared, you see sense and make a U-turn on this one.

[Carl Petzer]

@Marie Casabonne 

Can you please clarify whether these changes will impact recipes that send a message to a ticket based on a specific action? Currently, we use status changes to send automated messages to requesters (in thread) informing them of actions taken and further steps. This is absolutely essential to the way we use Halp in our org. Thanks in advance.

[Michael Hamrick]

Please stop breaking and dismantling Halp and acting like you're giving us a wonderful gift. It was perfectly fine until Atlassian touched it.

Hidden Projects is not a feature, it's a bug fix.
[JSDCLOUD-12305] Atlassian Assist direct message per user queue visibility - Create and track feature requests for Atlassian products.

[Omar Hutchens]

One thing I didn't see was if changing the bot's name was still something we can do? 

I haven't been able to get it to work and happy to submit a request if needed for investigation. 

[Marie Casabonne]

Hey everyone, thank you tremendously for reading the post and sharing your feedback (both positive and critical! It’s all helpful for us!).

I’ll address the most recent comments here in one post, but first want to re-iterate a guiding principle that went into these changes:

• Security & Trust: Jira Service Management has more robust set of well defined of user roles and permissions. In bridging the experiences together, there were certain cases where we ultimately needed to make an experience tradeoff in favor of supporting stronger security requirements.
• Efficiency: There are many capabilities that Jira Service Management delivers out of the box that are much more robust than what Assist supports today and what would be possible in a chat-first interface. There are other capabilities, however, that Assist thrives in, particular around real-time, conversational capabilities. And there are loads of things we want to expand upon there! In order to do so effectively, we’ve made some tradeoffs to ensure that Assist is not unnecessarily to duplicating functionality, which in turn enables us to focus on delivering better chat-first capabilities faster. 

@Ricky Jordan  - As noted in the image under Updated App home interface, users will have a link (right next to “raise a request”) to the Jira Service Management portal ticket list view. Jira Service Management already has a comprehensive ticket list view that we will be leveraging (vs rebuilding). This allows the Assist app home to be a surface for help seekers to discover all chat-based request channels powered by Assist, while still providing access to their full ticket history (whether they raised those requests from app home, a request channel, the portal, or email) in a unified view.

@Phill Saldana-Bailey - I hear you and others around the pushin + ticket emoji feature. This one was a hard decision to make, but here’s why we made it. This feature requires that Assist have permissions to go delete users comments in Slack. This is a high-risk requirement, and while we understand this functionality has its benefits, ultimately we’ve made the decision to reduce the risk surface area for all of our customers. This feature is the most notable impact of that decision, but will allow us to reduce the scopes needed by Assist in the future while still delivering core ticketing capabilities.

@Carl Petzer  - These changes will not impact Halp recipes. However, Halp recipes will no longer work after Halp is officially shut down in June, 2024. Is your team migrated to JSM or are you still on Halp? When you do migrate (or if you already have), you’ll want to move your Halp recipes to Jira Automations. The exact behavior you have (status updated —> send automated message to ticket thread) can be replicated using Jira Automations. In addition, using Jira Automations also unlocks a much broader set of functionality, stronger security, and audit logs!

@Michael Hamrick  - Hidden projects is built to mirror an existing Halp feature which functions in exactly the same way (but with a Halp queue vs a Jira Service Management Project). We built the feature into the Jira Service Management chat settings to allow for an easier transition for Halp customers to Jira Service Management. We hope to continue to expand on it in the future to allow for more specificity into service desk visibility and access via Assist in Slack.

@Omar Hutchens - Yes, the Assist bot's name is still customizable. You do this directly in Slack's settings & administration. Instructions below:

1. In Slack, go to Settings & Administration > Manage Apps.
2. Find Assist in your list of installed apps.
3. Go to the Configuration tab.
4. Scroll down to Bot User and select Edit to rename the bot.
5. Save changes and refresh your Slack window to see the new name.

[Ricky Jordan]

@Marie Casabonne I don't think Jira understands that many of the HALP/Assist customers that were forced to migrate to Jira, do NOT want to leave the Slack app.  Myself and my customers do NOT use channel submission and users submit tickets from the assist app (search initiated or from the button in the slack app) so a channel list is WORTHLESS!.  NOTE: The Browser is helpful for admins to setup automations, request types, admin items, search and access more advanced items and tickets.  But to the common internal ticket submitter via slack, they do NOT want to leave slack. 

Let me ask you this.  If you are an internal user that submits a request/ticket in Slack via Assist, and communicate 2 way via threads in Slack, and you could previously see ALL tickets/requests (aka threads) in a list in assist that you can filter (my open requests/tickets, closed, etc).  WHY would you want to have to leave slack to see this list moving forward?  The process would now be goto assist app in slack -> click help center button -> browser opens and needs to auth (hopefully SSO with Slack and NOT another login that the user has to keep track of and be confused as we never assigned them a sign in for it and it's not secured by our IDP and SSO/MFA -> and then they see their ticket list -> they click their ticket finally (YES 3-4 steps later instead of 1 step via list in slack app before these changes!  And THEN they can respond but now they are responding in the browser and NOT the slack app? so why need the slack app?). 

I get it if a requester is more advanced and wants to SEARCH for a ticket with a view more intricate with details that slack can't provide.  But the average requester wants convenience and most likely WONT leave slack/assist and if they have to, they will just rebel and send a DM...  This is what made HALP/Assist so great, we could have a ticketing system that existed in Slack, that was formal, and had a more advanced interface via web browser IF needed...  They can view their open tickets in a LIST RIGHT INSIDE OF SLACK AND RESPOND IN THE THREAD THATS LINKED! lol

Jira isn't thinking modern times and is overcomplicating this whole thing...  As mentioned, many customers if not all that used halp/assist liked it for the SLACK integration when using internally.  (zendesk and other competitors apps in slack weren't true 2 way slack standalone). Not all of your customers use Jira/Assist with external requesters, some are internal only (mainly the majority of my MSP customers.  Why are you taking away things that made HALP/ASSIST successful?  Why break that up?  I understand security concerns on some items, but they are already logged into slack via SSO, they are the private requester that is on the ticket and or a follower of that ticket, why take away a list view and FORCE them to goto a website they haven't had to goto in 2-3+ years of using HALP/ASSIST?  Why add more steps? seems so counterproductive.

----

Also I will add that my customers, especially one right now that has spent thousands of dollars for me to create and setup their new JSM environment, aren't pleased and almost want to abandon the project to find a more slack friendly solution as assist slack app is being torn apart...  (yes the open request list view being taken away is a big reason AND THEY EVEN USE IT WITH EXTERNAL REQUESTERS!, the agents want to see current open tickets in slack and NOT have to navigate away and have 2-3 windows open).  This isn't a good look for JSM at all and the responses show.   And to top if off you change this (aka take important functions away) within 30 days of the public announcement.

This whole thing is almost like microsoft aquiring control of the MacOS operating system and taking away all of the good things that made MacOS successful and overcomplicating things and wondering why people aren't happy LOL.....

Just unbelievable for a professional product and solution....

[Majken Longlade]

@Marie Casabonne the push pin feature would be useful even if it didn't delete the comments. Getting all the messages into the ticket is the main goal. Maybe it could reply to the extra comments in thread with a link to the primary thread?

[Ricky Jordan]

Now that the assist update is live today 10/11/23 and we get to test drive it...

lol.  i still don't get how Jira thinks it's ok to take away the list/filtering of tickets for a requester (and agent of course), and push them off of slack/assist and to create an account in the browser just to see their open tickets and keep track of them.  WHY WHY WHY have someone leave slack??  So counterproductive.  Not sure who the genius is that decided this was a great idea.

Not to mention now the users leave the SECURE slack environment that has company SSO protected by conditional access/MFA and onto a rogue unmanaged atlassian/JSM account they now need to sign up for with an unmanaged password, no SSO, etc.  The whole experience for a user pushes them away from using a ticketing system and just reverting to sending a DM to the tech dept.  Seriously who thought this was a good idea? LOL

The only thing that might ease the pain is if you allowed our company to have JSM sso on the house, if not then what's the point?  They still have to leave the slack easy to use one stop experience and goto a clunky browser experience they could care less about...

You have forever ruined the slack experience.  NOT EVERYONE needs to be in the browser!! 2-way ticketing inside of slack withOUT ever leaving slack was the beauty of HALP and ASSIST.  Stop taking us back to old fashioned ticketing that all of us wanted to move far far away from until halp/assist came along.....

My MSP clients and I will be moving elsewhere (total of 1500+ users).   

Thanks for forcing this on your customers without asking them if a MAJOR feature of assist should be changed......  UNREAL...

End on a positive note after taking away a KEY feature? -- sure, the rest of the assist app polish on the UI AND UX is great!  Lot's of good things here.  BRING BACK THE LISTS!

[Kris Monier]

The UI change on the tickets is SO SO SO BAD. It's literally giving my team members a headache. I spend all day looking at the queue and I can't tell what's going on anymore. Do you hate your users? How can we opt out of this change?

[Jules Avila]

Hi Marie, thanks for the communication. I have mixed feelings since I know every change comes with lovers and haters as I'm also PM. Just in my specific case, I've been pushing hard to have Assist implemented and used by our teams, and now some of my selling features have disappeared, this is not good at all. So, I hope this message and the rest of the feedback are useful for you and your team and help us to get prepared for new upcoming changes. The only feature that I won't forgive if you deprecate is the sync of the thread with the ticket since is the main reason I selling the company they don't need to go out of Slack.

Thank
Jules

[Marie Casabonne]

Hi @Jules Avila - thank you for the feedback. I do want to clarify that comment syncing on a ticket thread between Slack and JSM is not being deprecated. It's core to our product being a two-way conversational ticketing experience between helpseekers and the teams that assist them!

I believe there was some misinterpretation around what is being deprecated re: syncing, and the one feature where we made a small update to thread syncing was with respect to private chat requests. The change we made is that when private chat requests is enabled for your JSM project, once a ticket is made in a request channel, Assist no longer monitors the request channel thread that the request originated from to delete any comments added to that thread. The ticket itself, however, is still sent to the requester via the Assist app, and all comments on the private ticket sync between Slack and JSM as they do today.

[Jules Avila]

Thanks, Marie! I know. Just saying that this is the main feature and based on recent events, deprecating some features adds a little stress on this side. Btw, great work with Assist in general, and let me know if I can help to contribute to making the product better. Cheers!

[Danny Fang]

Hi @Marie Casabonne 

I have a concern about this change:

"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 moved to Assist because we want to move away from email, and we have all email notifications disabled account-wide. For requests created in the Raise a Request in Assist bot, and an agent were to mention another user to collaborate, they no longer get any notification via Slack. What is the intent with this experience, and why are notifications fragmented depending on if the ticket is in a request channel, Assist bot, agent channel, or if the user is agent, reporter, or participant?

[Ricky Jordan]

@Danny Fang agreed, same thing over here.  We had it dialed in (and many of my customers had me implement this in their assist/jira enviros), by setting up an automation that would add other agent(s) aka managers as followers to tickets.  For example an IT staff of two, if AGENT#1  took the ticket, then AGENT#2 was added as a follower and vice versa.

This week was fun trying to see what open tickets we had so we can help the requesters quickly... unfortunately there is no more list to reference and we are forced to goto the jira website instead of stay in slack.  Still don't get the logic behind many of these changes.  Seems rushed and like they didn't pay an ounce of attention to their customer base. 

Forcing HALP/Assist legacy users over to JSM is one thing, but taking away the things that made HALP/Assist great, just makes no sense unless they wanted to buy them out and squash them :(

So painful to use now without leaving Slack.  Super confusing for our users, and now for my consulting firm, i have angry clients of mine that spent thousands configuring their JSM/Assist/Slack to their liking and now they are finding out that major features/flows have been removed and they either are out that $$ they spent and have to move to another system, or they just use a system that was made clunky and stripped of its goodness.

[Michael Young]

Just to chime in here.  I am one who likes change and is quick to adapt.  I do have to say, though, that one change is a step backwards for us rather than an improvement.

The new behavior of Private Chat is very disappointing.  One of the main reasons we have it turned on is to direct communication on the public channel to the ticket.  Sometimes there is information requested that we do not want the whole company to see (you know, security reasons and all).  That is why we appreciated that once a ticket was created, nothing further could be posted publicly.

This makes the Assist app less useful for us.

[Ryan Pigeon]

After the updates we have seen a non-consistency associated with issues that are raised by users that are not put into the request channel to have the Assist Bot then post the thread to that channel. This causes issues with the privacy of these requests and when we attempt to make the threads private now, it will not sync the communications. Is this a bug? Or is this how its supposed to function? Either way this causes major issues for our team. I am all for new updates and making the changes, but the current state of these changes are far from ideal and would really need to know how we can fix this.