[CLOSED] AMA: Automation and Playbooks in Jira Service Management

[#1]

UPDATE: We've wrapped up our Ask Me Anything for Automation and Playbooks! Thank you so much to everyone for taking part and sharing your questions and feedback. Here is the recording if you'd like to revisit any of the questions that were covered: https://atlassian.zoom.us/rec/share/z9F1y8f3YvuecoNbB2uKel7pXC8Et-1UTjlUys5p8tH7he_Gu3ik04H2DHOEpT3L.gxgQmjsAuo6gTS9l?startTime=1765471911000
Passcode: =mK5g0&s

Also, be sure to watch the Jira Service Management roadmap to get updates on new features. Lastly, please keep the questions and conversations going via Atlassian's Jira Service Management Community page. We look forward to continuing these conversations with all of you!

---

Hi Community!

We are back again with another AMA session, this time with Senior Product Manager @Makarand Gomashe and Product Manager @Samruddhi Zagade

We are inviting you to ask us anything about automation and Playbooks in Jira Service Management. We’ll answer your questions LIVE at 9 am PST / 12 pm EST on Thursday, December 11th, 2025. Register here.

We’ll cover all Jira Service Management has to offer when it comes to automation and Playbooks. Feel free to ask about:

• Our vision and roadmap for automation / playbooks

• How to get started with automation and playbooks functionality in Jira Service Management

• And anything else you can come up with!

You don’t need to wait until December 11th; ask your questions in the comments below. We will make sure to answer them here and also cover the answers in the AMA on 12/11.

[Milad S_]

Hi Jack,

Thanks for providing the opportunity. Are you considering offering AEDT time as well?

As for the question, I am not sure how best to mix workflow, automation, and playbooks in a use case where the agent needs to review the request and then trigger automation to take action (e.g., create/update an object, create another ticket, etc.). 

Currently, we use an automation triggered by workflow transitions: when a workflow transitions to a certain status, the automation kicks in and, at the end, adds comments and transitions to another status, depending on whether it was successful. This is like an agent handing over to Automation by changing the status. Is/will it be a benefit to adopt the playbook in this scenario? 

Also, we are training the agent so that you can update, comment or transition. Are we moving towards a future where we tell agents to follow the playbook, in which you may be asked to review, update, transition, add comments, or trigger automation? In this scenario, do you foresee a time when there is a separate playbook for each status that requires agent involvement?

Kind regards,

Milad

[Andrei Tuch]

Some of the feedback we have already given to the Playbooks team:

1) It should be possible to set a step to Mark as Skipped. In some situations a particular step may be inapplicable to that specific work item, and then it is meaningful to distinguish between “yes I have done this”, and “I have not done this but I am moving forward with the playbook”.

2) Our users would love to see the Playbook Details’ Conditions work on an arbitrary custom field, particularly a dropdown (single-select or multi-select) field. Essentially they want to create distinct playbooks for e.g. different countries within the scope of a single request type. Inside a given Request Type, there may be different playbooks depending on one of the custom fields.

3) This is already available I think: being able to take a Done step and mark it as Not Done. So, to reopen it.

4) Playbooks should be available in regular Jira as well, not just JSM.

5) It would be great to have a Description field to be shown in the backend of the Playbooks section in Project Settings, so that they can differentiate between Playbooksthat are similar in nature, but intended for slightly different purposes. Basically, more organization of existing playbooks for project admins. In the project backend, there is just a long list of Playbooks with almost the same names. For agents and admins, it is difficult to keep track of which playbook is for which request workstream. The Description field would be visible in the list right next to the name of the playbook, and would give an easy indication of what this particular playbook is for. E.g. “For Catering customers who serve both coffee and pastries, and have more than five locations”.

6) Playbooks can be filtered to a particular status (via JQL), and then they will only appear once the ticket reaches that status. This is correct behavior. However, once the ticket leaves that status, the Playbook and its execution log​ disappear completely. There is no way to go back and check already completed playbooks within a ticket’s lifecycle without transitioning that ticket. This is a problem. Either have a separate tab for completed playbooks / a distinct Execution Log that shows a universal history for all playbooks in that ticket, or at the very least, make execution logs visible in the ticket’s primary History tab.

7) Currently, I can check off any step within the Playbook, including a later step even when an earlier step has not been completed yet. In some cases this makes sense - e.g. if there are multiple steps to check off and they are done in any order, it does not matter which one gets done first - but it should be configurable to make the steps a strictly sequential thing. So for example, if the last step in my playbook is an automation that collects data and sends it off somewhere, it should be possible to set that step as “cannot be run/marked done until the previous step is complete”.

8) In a similar vein, it would be good to take the conditionality that now applies to the entire playbook - i.e. it will only appear for this work type, for this request type, for this JQL filter - and extend it to each step. So for each step I could add a little supplementary JQL, like Only Show This Step If “customfield_YYYY” IS NOT EMPTY. This would greatly help make a single Playbook usable for a workstream that branches slightly, depending on the original input (e.g. onboarding a new customer, but different steps depending on what business the customer is in).

9) There is currently a kind of visual bug, where if a step has been Marked Done and then Marked Undone, the UI still shows a big Success button that implies the task has been marked as completed. This Success icon should disappear if a task is Marked Undone.