Playbook - workflow - automation interactions. Is it possible to block a workflow transition

[Paul Marachlian]

Hello,

I'm discovering and trying Playbooks in JSM.

Is it possible to block a transition due to incomplete Playbook execution ?
Should it be linked to a field/status to validate in the workflow based on the feild value ?
Or am I missing the point completely on the Playbooks usage.

Thank you

[Andrea Robbins]

It is not possible. Only thing you can try is having a done checkbox at the end of the playbook which is an automation rule that sets a field. Then your workflow condition is that the field cannot be empty. 

[Olga Cheban _TitanApps_]

Hi  @Paul Marachlian !

Quick note on the concept first: Playbooks are essentially in-ticket runbooks for agents. They guide the work, but the workflow engine has no visibility into whether the steps were actually done. That's why a validator can't reference them directly.

If you need real enforcement, you'll need to move that procedure into something the workflow can read. A dedicated checklist app is usually the cleanest fit. In our own JSM setup, we use our solution Smart Checklist for Jira.

The relevant piece for your case is the mandatory items feature combined with a workflow validator - you can mark the critical steps as mandatory (via the Markdown editor or through the UI menu), and the validator won't let the ticket move forward until those specific items are checked off.

A few practical notes that might save you time:

• You can apply the checklist automatically to new tickets based on request type, so agents don't have to add it themselves
• Marking only the critical steps as mandatory tends to work better in practice than enforcing the entire list. Agents still see every step, but the gate is reserved for the ones that genuinely matter
• If it's useful for your process, you can also make checklist progress visible to the requester on the customer portal, so they can see where their ticket stands without having to ask. Entirely optional, but a nice touch for transparency

Happy to share more details if it sounds like a fit

[Monika Ambrozowicz_Seibert_]

Hi @Paul Marachlian, afaik it is not possible. JSM Playbooks are designed more as guided task lists for agents, so they don't natively integrate with Jira workflow transitions as enforceable gates. So to block a transition until work is done, you'd need to connect Playbooks to something the workflow engine can actually read, like a field value or a status. The typical workaround is to use a custom field (such as checkbox or select field) that an agent updates manually when the playbook is complete, then add a workflow validator that checks that field. It works, but it's manual and easy to bypass.

If this behavior is important to you, and if you're open to a Marketplace app, I'd suggest looking at Didit Checklists. Full disclosure: I am affiliated with the team that built this app. 

What Didit does differently is that the checklist itself becomes the gate. You define a checklist template with the steps agents need to complete (similar to what you'd put in a Playbook), attach it to the issue (manually or automatically via Jira Automation based on issue type, project, or other conditions), and then configure a workflow validator that blocks the transition until all checklist items are marked complete. 

This gives you the structured step-by-step guidance of Playbooks combined with the enforcement you're looking for at the workflow level. You can also auto-attach the right checklist template to new issues so agents don't have to think about it.

Let me know if you have questions, I'd be happy to help. 

[Steve S_]

@Paul Marachlian Playbook allow the ability to provide a standardized procedure doc embedded in the ticket that the assignee can follow.

If you want to expand on Andrea's post (e.g. tags/update issues when all Playbook steps are completed, then report on those tags), you could add a step to that automation that effectively:

• Compares the tag to the issue's status
• Then do something like "IF tag = blank & status = <incorrect status> THEN update the ticket's status back to <desired status prior to approval> AND add comment to ticket AND send email AND comment" etc. etc. 

You would need to run that rule as a scheduled rule that runs daily, but this is band-aid approach that is open to fail as your environment grows.