Hi all,
Welcome to the next installment in my JSM Tips & Tricks series.
One of the more powerful features of Jira Service Management (JSM) is its native Asset Management capability, built on an integrated CMDB (Configuration Management Database). In JSM, this module is simply called Assets.
Assets allows you to define multiple schemas—such as systems, software, hardware, and more. Each asset object can have custom attributes that describe and help manage it. A common use case is adding an owner field (typically a user picker) to identify who is responsible for a specific item.
So now, imagine you have a well-maintained asset database containing servers, applications, hardware, etc., each with an "Owner" attribute. That owner is the go-to person for any incidents, issues, or changes involving the item.
But here's the challenge:
In the default Change Management workflow in JSM, how do you dynamically identify the affected asset, extract its owner from the Assets database, and automatically assign that person as the approver during the approval step?
That’s exactly what this article will walk you through.
You can use Asset Management combined with Automation to dynamically pull a user from a group or a specific person.
For example, your Asset table can include users who belong to certain LDAP groups. With the right setup, you can leverage automation rules and smart values to reference and act on these users easily.
A common use case would be an attribute like "Business Owner" within an object—such as a Software Asset Item—which identifies the responsible user linked to that asset.
To test the setup, I created a few asset objects with designated Business Owners, assigning myself as the owner of the NoSQL Database item.
Next, in order to identify which asset object to reference within the change ticket, we need to create a custom field of type Asset.
When configuring the custom field, I set the objectType to Software Asset Item, named the field SW for short, and applied the necessary configurations.
NOTE: I named the Schema Testing-Nadon
Now, let’s review the workflow approval step. I’m using the default Change Management workflow provided by the Advanced IT Service Management template. This workflow includes a status called "Authorize", which represents the approval phase.
By default, the Approver source is set to Approver Groups. However, since we’re assigning approvers at the individual level in this case, I’ve updated the configuration to use Approvers instead of groups—although using groups remains an option if needed.
I recommend always using either the Approvers or Approver Groups fields for every approval step within a workflow—even if there are multiple approvals in the same process. Since both are standard fields, they can be configured dynamically based on the workflow's needs before entering the approval status.
In my typical setup, I populate these fields using Automation or a Post Function prior to the approval step.
Let’s walk through an example using Automation:
You can create a rule that triggers when the issue transitions into the Authorize status. Within this rule, you can populate the Approver field using a smart value that references the asset selected in the custom field we previously created (named SW). This approach allows you to dynamically pull the approver from the linked asset's attributes.
Now it's time to test the setup—and just like that, it works! Once the SW Asset field is linked to the issue, Automation automatically retrieves the Business Owner defined in the associated asset and sets them as the Approver.
Below is a look at the issue creation process and how it behaves after transitioning to the Authorize status.
NOTE: During the approval step in the workflow I did remove the Exclude approvers from lists so that I could be both Approver and Reporter
Have fun and feel free let me know if you want assistance with anything Jira!
…Robert Nadon
Robert Nadon
7 comments