Assist - Raise a Request from a link or Slack workflow

[Alex Poller]

Hi all,

Trying to set up the Assist bot to use in a shared incident Slack channel. Ideally, we'd like to limit the users from being able to post in the channel since there are over a hundred users and this could become unwieldy very fast. Previously, we've used a legacy Slack workflow to achieve this. We want to keep visibility in the ticket threads amongst the large group of people, as well as the ability to comment.

We're migrating to using Assist to keep things tracked. I'd like to keep the workflow as simple as possible WITHOUT allowing posting permissions.

• user clicks a button
• user fills out a form (ideally the Assist form, connected to our request type)
• user triages with support team over Slack

Is this possible within the existing application?

I'm also open to using "raise a request" as a step within a Slack workflow, but this also does not appear possible with the new Slack workflows. Every other option I've found either adds an unnecessary extra step, which could be confusing to the user, or requires the user to be able to post to the channel.

[Brendon Wilkinson]

Interesting approach; I hadn't thought of doing it that way; it's not the ideal way to do it at all, but I will play around and see if it could help bridge the gap for us. Thanks

[Brendon Wilkinson]

@Alex Poller Did you find a solution to this? I am attempting to move to Assist but having a similar issue. Currently I bookmark a link to the support portal page for intake of new requests and then using automation to post to a slack channel, which prevents users from being able to post directly in the channel. I was hoping that there would be a way to keep this flow but link the created request to Slack using Assist, but that doesn't seem possible either.

[Alex Poller]

Unfortunately no. I put together some convoluted workarounds using automations, but this is clunky. Basics below:

• User submits via Slack workflow to a restricted channel where posting permissions are allowed ONLY for the workflow. Make sure to allow comment permissions for all users you want to be able to comment on the ticket.
• Workflow posts to the channel
• Assist auto-generates a ticket with the workflow as the requester and unceremoniously dumps all text into the "summary" field
• many automations take care of editing this ticket's fields as necessary

For example, I take the first comment (which has all of this dumped text data) and copy it to the "description" field so I can have a proper ticket description. I pare down the summary field into something manageable. For example I use the smart value {{issue.description.substringBetween("ITEM-A* "," ITEM-B")}}, which takes the text string between the values ITEM-A and ITEM-B in the issue description. Don't do this for the summary field, since it cuts off after a certain length.

Similar workflow to capture the requester data and any other fields I'd like intelligently captured. I use the following to capture the Jira user ID of the submitter:

{{issue.comments.first.body.substringBetween("[~accountid:","]")}}

This pulls the Jira User ID from that first comment, where text is dumped. This can be stored in the automation for later use or applied directly to an "edit reporter" automation, so it doesn't show up with Atlassian Assist as the reporter.

Really would've saved me a lot of time if Atlassian just supported a way to do this.