Need advice for building out a process in JSM

[John Izquierdo]

TL;DR what would be the best practice to building out a process/procedure for decommissioning hardware/servers in a JSM Space without over complicating and cluttering things up?

Our Systems Manager is requesting we setup a process/procedure require certain steps are taken to decommission hardware/servers before it can be closed.

Currently our JSM Space has the typical ITSM Work Types: Incident, Problem, Service Request, and Change Request. My thought was to do the following:

1. Add Sub-tasks to our list of available work types
2. Create a new Request type under Service Requests and name it "Decommissions"
3. Create an automation that creates sub-tasks of the list of things to do for the decommission
4. Update the Workflow for the Work Type Service Request that prevents transitions to Done if the Request Type is Decommissions and the sub-tasks haven't been marked as completed

The above solution I came up with seems a bit much and become an issue for future Jira Admins when troubleshooting potential problems in the future.

Is there a better way to accomplish this without Duct tapping it all together? Would Playbooks be a viable solution? How can we prevent transition to done before other tasks are completed.

Any and all help would be much appreciated.

Thanks!

[Hari Krishna]

Hi @John Izquierdo 

If the goal is to make sure decommission steps are followed without cluttering JSM, the simplest and cleanest way is not to rely on lots of sub-tasks and heavy automation.

A better approach is to keep everything in one Service Request.

Create a request type like “Hardware / Server Decommission” under Service Requests.
Then add one checklist-style custom field (checkboxes) for the required steps — backup done, access removed, monitoring disabled, asset updated, etc.

Next, add one workflow validator on the Done/Closed transition that checks:
“All checklist items must be completed.”

This way:

No extra work types

No complex automations

No sub-task sprawl

Future admins can easily understand it

All steps are visible on a single ticket

Automation can still be used lightly (for example, to pre-fill the checklist or add a reminder comment), but it shouldn’t be the core enforcement.

Playbooks are fine for documentation and guidance, but they can’t enforce completion, so they shouldn’t be relied on for this use case.

[Marc -Devoteam-]

Hi @Hari Krishna 

This does require a 3rd party app for embedding checklists in the instance.