In this article I’d like to show you how you can work with Assets and Automations to further enhance the experience of the case “Order a new device“ by:
Offer a pick list of devices instead of a text field
Automatically fetch and assign the manager as approver of the request
The steps below can be used for other cases too, wherever you have a standardised “pick list”(applications, service requests, travel, lunch) for requesters to choose from and if a third party related to the requester should be involved to approve a request. You can also decouple these two enhancements and use only one of them.
If you are on Jira Service Management Cloud Premium or Enterprise plan you have access to the Asset functionality which offer capability to manage master data and use it in your Jira issues.
In Assets the each data point is an Object, organized in Object Schemas (call it f ex Internal IT Assets) , can be of different Object Types (Device Models, Organisations, Offices) that have attributes (f ex status, serial number). You create schemas, object types and attributes so it suits the needs of your company.
You have a few options to consider about introducing data management in Jira. You can:
Maintain this data in Jira as your master. Add, remove, change is all done in Assets.
Import the data from an external source via csv. You need to ensure to import new data regularly.
Use an importer app to sync in data from an external source for example from any database, Azure AD, InTune, Google workspace or Jamf. These sources will continue to be the master of the objects and Jira will then have a replica of the object that we can use for the issues.
The neat thing with the importer apps is that they establish the whole object schema, object types and attributes when you install the app. You don’t have to know the data model in your source and build it up in Assets before syncing in the data, the app does it for you. It's also possible to add your own object types and attributes to a synced schema to extend it.
Let us take the Request called “New mobile device“ that you get when you create a project with template IT Service Management. It is connected to a workflow with an approval step to ensure someone is approving the order.
Having the requester choosing an approver in a field amongst many users might not be ideal or safe. What if they choose the wrong user? Normally it is the manager of an employee that approves a purchase.
The field for device is free text which means that different users will describe what they want in different ways. That will cause more cycles of clarifying whats needed and what is offered, causing loss of time and possibly some friction as expectations can’t be met.
What if you already have a defined number of models to choose from in your business? What if you already know who the manager of the user is? And what if you have this information stored in Azure AD or Google Workspace?
With Assets and Automation we can enhance this request form to be a little bit more automated and relevant.
Below is an example of an object schema set up by the InTune importer app. I have models as an object type that has attributes like Name, Description, Manufacturer and Status. It is good to have a status attribute as the models offered will change over time and you might want to keep an archive.
Create an Asset field fex “Device Model Choice” and configure this to fetch all models with status active. You can choose that attributes to show on the portal and what attributes should be displayed for the agent.
Add the field to the screen and request type.
In my case where a user is requesting a device we also wanted do know the manager of the requester.
This information is often born and updated in an already existing directory service, a master, that you do not seek to replace with Jira assets. With the importer app in place you will instead sync the data from your source to keep the latest information available so we can use it in Jira issues.
In the example below I have used the importer app for Azure AD plus extended that with a Jira user attribute. An additional automation is needed to automate the mapping of Jira users to User objects.
We want the automation to go to assets and via Jira user of the reporters find the user object of the reporter, find who the related manager is of that user object, take their Jira user and stick it in approver field on the Jira issue.
Here is how to build it
Trigger = Issue Created
If = condition on Request type
Then = Look up object, I used this AQL
ObjectType = Users AND object HAVING inboundReferences("Jira User" = {{issue.reporter.accountId}})
Then = Edit issue field
{{lookupObjects.Jira User}}
Removing the user picker for approver means less fields on the order form for the requester
Fields is a list of option instead of free text is easier to work with
Adding more attributes like description gives the reporter more information about their choice
Improved request for the agents
Easier to fullfil and set the expectations of requesters on device choices
Less time spent on validating that the right person is the approver
Less time spent on retrieving more information from the reporter
Best regards
/Lisa
Other articles on similar topics:
Lisa Forstberg
Atlassian Expert Consultant
[LN Forstberg AB]
Gothenburg, Sweden
79 accepted answers
0 comments