🚀 Create automation-driven Playbooks for agents in Jira Service Management

[#1]

We’re excited to share that you can now create automation-driven Playbooks for agents and responders in Jira Service Management, accessible directly from the issue view.

Available for Jira Service Management Cloud Premium and Enterprise customers, the new playbooks feature guides agents and responders through the execution of complex, repeatable processes. With playbooks, you can define standard operating procedures (SOPs) for your teams, including instructional steps, and automated steps that help them resolve issues faster.

Take a look at how to configure and use them in this demo:

A quick tour of playbooks

Playbooks in Jira Service Management can be thought of as a set of ordered rules that you define for your agents and responders. They’re configured at the project level, and can be made and managed by anyone with project admin permissions.

With playbooks, you can define the sequence of steps to complete in each playbook, giving agents a clear procedure to follow in difficult or stressful situations like incidents for on-call agents. These playbooks also standardize and assist agents responding to a JSM issue, such as onboarding steps for an HR managing a new employee or steps to verify and grant access to systems for IT support. For each step you define, you can choose one of two-step types:

1️⃣ Automation step: With this step type, you can let agents manually run a pre-configured rule. When an agent lands on an automation step, can input any required values from previous steps and then click the “Run” button on the step to trigger the rule. The playbook will then run the rule, show the output directly in the issue view if successful, and add the run and results to the execution log. Each step can have a description to help agents learn about the context of when this should be triggered.

💡 You can use these steps to pull agent-inputted information into your rule run. For example, you can trigger a rule to get the virtual machine ID in step 1, and then in step 2, prompt them for that ID in order to trigger the automation step to restart that virtual machine. If not needed, you can skip step 2, and trigger a rule in step 3, to execute a preconfigured runbook on that VM. This gives agents both power to quickly take actions on click of button and control over the steps to run based on the context.

2️⃣ Instructional step: Text-based steps for your agents, where you can write instructions on how to complete a step manually. You can also add links to instructional steps for context (like a link to a piece of documentation). Once the agent has completed an instructional step, they can mark it “done”.

💡 Once it’s marked as done, the playbooks execution log will capture who marked the step done, and when they did so. That way, your team can keep a clear paper trail of what actions have been taken so far on an issue or incident.

As a note: while playbooks are configured at the project level, the automation rules you embed in your playbook automation steps are not bound to that project. They’re still able to perform actions across projects when run from within a playbook. They can also still perform actions outside of your Atlassian products, like running scripts on AWS or Azure.

Currently, playbooks can only map to one project, meaning playbooks will only appear to agents under the project they've been created in. That said, they can be mapped across issue types, request types, and groups within a project to make it easier for your agents to discover only the relevant playbooks they need.

When and where to use playbooks: a few ideas

The video demo above features a playbook designed for incident management—but that’s just one way you can take advantage of them. You can also build out playbooks for other intricate processes across your business, like:

• Validating a successful change request

• Completing new employee onboarding tasks

• Executing an employee leave approval process

• Verifying permissions of an employee and granting new access if requested

• Updating your CMDB when assigning hardware to a new employee

By defining playbooks for these repeatable processes, it can help you and your agents feel confident that they’re executed the same way every time. And by empowering agents and responders to tap into automated steps, you can also reduce manual and tedious work for them, and reduce context switching by allowing them to stay in the issue view.

When you’re able to create a clear path forward for your agents, they can resolve issues faster. And if they do need to bring in extra help to resolve, execution logs keep a clear audit trail of everything they’ve already done. That makes it easier for teammates and escalation managers to jump in and get context quickly when they’re needed.

Creating your first playbooks: resources for you & your team

If you’re ready to start building playbooks for your team, we encourage you to check out the support documentation below:

→ Getting started with playbooks

→ Create and manage playbooks

→ Run a playbook and view outputs

We look forward to seeing how you use playbooks to standardize your own processes. And if you have any feedback as you get started, feel free to share it below—we’d love to hear about your experiences.

Questions or Feedback for us?

If you have any questions or feedback for us, please book some time based on your availability using this link: https://calendly.com/makarandgomashe/playbooks-in-jsm

[Michael Bachmann]

Please hide the Playbooks panel if there are none for the current issue.
The JSM UI is already complicated and overcrowded as it is, introducing a new panel in the middle of the UI that in most cases will probably be empty is very annoying for the user.

[David Berclaz _Apwide_]

Fair point Michael.

Playbooks look great, but it would be better to hide the panel when there is no playbook.

[Vincent Leblanc]

It would be beneficial to have the ability to include images in the instructional steps.

[Italo Lobato]

Other than hiding the panel, I think we need flexibility to change the Playbook step status many times things can go wrong and we need to redo the step but currently once the step is marked as Done we cannot change it.

Imagine the Automation to restart the Azure VM fails, how would we be able to trigger it again?

[Makarand Gomashe]

Hi @Michael Bachmann @David Berclaz _Apwide_ 

Thanks for the feedback. Playbooks is a new feature and aims to be the first assistance of any JSM agent trying to address an issue. Through Playbooks, agents can streamline and focus on the right set of actions. With a one time setup of Playbooks, agents and business can benefit in multiple processes, and after the setup, the panel will not be empty.

But in cases, where you don't need a Playbook for a Project at all, currently we do offer a way to disable Playbooks from Project Settings -> Features, after which the Playbooks panel will not show up on the issue view for that project.

[Makarand Gomashe]

Thanks @Vincent Leblanc , adding images in the instructional steps is definitely one of the key capability planned in the next set of enhancements.

Currently, you can provide a link (in the step description) to some resource such as a confluence page, which has all the images, as per the need.

[Makarand Gomashe]

Hi @Italo Lobato 

Thanks for the question. You can actually re-run all the automation steps.

We do understand that when issues are re-assigned or after a long time, you will need to fetch the latest data. So not just in case of failure, but re-run is needed to validate and get updated information. For example, getting the latest data from New Relic on a service of interest, or calling an API to get latest set of permissions/groups of the reporter to fulfil an access request - hence, we do support re-running automation steps any number of times.

In your example, if the Automation to restart the Azure VM fails, you can actually re-run it.

I recommend trying out the Playbooks feature and keep sharing your insights/feedback as you explore more.

[Makarand Gomashe]

Hi @Michael Bachmann @David Berclaz _Apwide_ @Italo Lobato @Vincent Leblanc 

I hope the above responses help address your queries. If you have any further questions or feedback for me and would like to chat over a call, please book some time based on your availability using this link: https://calendly.com/makarandgomashe/playbooks-in-jsm

[Michael Bachmann]

@Makarand Gomashe making this an all-or-nothing approach per project is rather detrimental to the feature.

I would certainly argue that there won't be a Playbook for every issue type / request type and then having such a big empty panel is much more confusing to the user who might expect something useful only to find an empty panel.

Admittedly this might hinder us from using the feature at all as it just adds to much visual noise to the issue view with little to no advantage for most of our issues/agents.
We have over 100 request types and although Playbooks might be an interesting idea for some specific request types adding this empty panel will just be annoying for the other 80+% of issues/agents.

[Matthew Challenger]

Agree with above comments. Please hide the panel or, at most, only display to admins.

I see that Playbooks is one recommended Use Case for Onboarding steps. We currently use Sub-Tasks to manage onboarding steps. In the Atlassian team's opinion, what would be pros/cons to using PlayBooks vs Sub-Tasks?

I like the Playbook's ability to confirm an Automation's success status back directly on a ticket, without it being in a comment. In general, I'd love for that kind of functionality for Manual Triggers and I will explore wrapping our Manual Triggers in a 2-step Playbook to have it more seamlessly shown.

[Rune Rasmussen]

I'll join the choir here.
The Playbooks panel absolutely must only show when Playbooks are actually available. I get that Atlassian wants to display their cool new feature, but it's not doing anything good when it's just there, empty, and in the way.
We want to use it but as mentioned by @Michael Bachmann there won't be Playbooks for every issue type/request type.
We also won't have Playbooks available for everything from day one.
So this large panel is just going to be in the way and annoy 95% of our JSM users. It becomes just another thing to live with and there are many of those already.

So here is what's going to happen, if we turn on the Playbooks feature as it is right now.
People are going to come and ask us why the panel is there when there are no Playbooks in it.
We'll have to respond that "Because Atlassian would rather push it in your face than let it be hidden when empty", or something along those lines.
That will only make Atlassian look bad.

Here is what I would rather have happen.
We introduce our users and project admins to the Playbook feature.
Someone tentatively asks "then what when there are no Playbooks? We won't need any" I can answer "Ah, don't worry. It won't show if there aren't any Playbooks to show".
That would make Atlassian look like they had though it properly through.

Don't get me wrong.
I like the feature, it's really cool, but it's not quite ready for use. Not for us at least.

Other feedback for things that could come in future iterations:

It would be very cool if we could branch steps. Maybe even make those branches dependent on Custom Field values.
It would be very cool if we could use custom fields for the Playbook scope (Show playbook for).
It would be very cool if a playbook could be re-run on the same request.

[Makarand Gomashe]

Thanks @Michael Bachmann @Matthew Challenger @Rune Rasmussen and everyone for the feedback. We are actively exploring all of the key problems mentioned above and we should have an update soon!

Also, as we plan our set of features for Playbooks, my team would love to chat over a call, can you please book some time based on your availability using this link: https://calendly.com/makarandgomashe/playbooks-in-jsm

[Wolfgang L]

Hi Atlassian, 

Great idea, on top of what others said (hide by default, rerun steps) I would like to make two feature requests, that would help us transition away from our custom solution.

1. Just like for forms, for some playbooks it might be a great to have a 'make public' option. Or even have some playbooks be public by default. Read only would already be a great way to display the requests progress towards customers.

2. Integrations. I'd love to see some workflow post function/validator interacting with playbooks. Also I was not able to get the playbook data via API (no system field, and no issue property). That would help make more custom integration possible. Also custom reporting. I understand that this point is something you'll have to wait for everything else is more settled. But just to keep in mind.