⭐️ Transform your portal (Part I): Personalise your select lists

[#1]

In this article we will explore the power of Assets in combination with Jira Service Management to allow users to select their own assets (equipment) when raising a request.

From endless scrolling...	To quickly select!

It sounds simple enough, but you do need to perform some configuration work that extend beyond your typical daily routine Jira administrator tasks. Just search on the keywords 'asset' plus 'reporter' on this community forum and you will find a lot of questions around the configuration of fields to only show assets related to the current reporter.

The concept

Assets is - according to Atlassian - 'The database of everything'. It offers a way to store objects in a relational database, and use this data in the context of your Atlassian applications such as Jira Service Management.

A very common use-case is to use Assets as an IT Assets database where an IT department maintains a database of equipment (Computers, Phones, Servers) and registers their ownership (Christina's MacBook), status (Returned for repair) and relations to other assets (Software installed on).

Whenever a Customer raises a requests on the Service Management Portal, it can be very useful to allow the user to select which equipment the request is for (I have a problem with 'MacBook, serial number 0016222344B').

However, it will not be very user friendly, if your Customer has to sift through a pick-list of hundreds of assets to find their own MacBook (and how would they even know which their MacBook is?).

So this solution is all about filtering the dropdown-list so that it will only show Assets that are linked to the current user (reporter). This is not only user friendly for your customers, but also efficient for your agents, when they have to create a ticket (based on an incoming phone call or walk-in customer).

⚠️ The prerequisite is that all hardware owners are in fact Users in your instance. But considering that the majority of portals do not allow anonymous access, it's safe to assume that your customers are in fact Jira users (with Customer access).

In case of Portal-Only-Customers: Portal-only users cannot be selected in Asset objects as Users. I'll include a 'In case of Portal-Only-Customers' section at each configuration to tackle that issue.  

The Assets data model

In this demonstration, the Assets Schema has an Object Type 'Hardware', broken down into Laptops and Phones.

Inheritance
The main 'Hardware' object type has been set as Abstract object type.
And inheritance has been enabled, so that all attributes are passed down
to its child object types.

These settings make sure that users cannot create objects in the
main 'Hardware' list, but are forced to create them in one of the
child object types (Laptop or Phone in this demonstration). Also
it ensures that all attributes configured on the Hardware objecttype
are also applied on all child object types. This creates consistency
in attributes across all child object types.

You can configure these settings in the Object Type settings,
on the tab 'Inheritance'.

The abstract 'Hardware' object type has attributes Model, Owner and Serial number. For this use case the Owner attribute is what matters: it is an attribute of the type 'User' so that Jira users can be selected as its value.

⚠️ In case of Portal-Only-Customers: In case of Portal-Only-Customers, you'll have to add an attribute 'Owner Displayname' of the type Text. You have to find a way that the display name is exactly the same as the actual Display name though!

If you have both Jira Users as well as Portal-Only users, simply add both attributes: Owner (of type User) and Owner Displayname (of type Text) and ensure that either one is filled. 

The field and its AQL

This demonstration uses a custom field called 'Hardware'. The field is of the type 'Assets objects' . Its configuration has been set as follows:

• Object schema: the schema in which the Hardware Object Type is managed
• Filter scope (AQL): objectType in objectTypeAndChildren("Hardware")
• Filter work item scope (AQL): "Owner" LIKE ${reporter.label}

The Filter Scope could also be configured as objectType in (Laptop, Phone). But by using the objectTypeAndChildren() function, we ensure that any future child objectType (maybe Tablets, Servers or Printers) will automatically also be included in this filter.

The Filter work item scope is where the personalisation magic takes place. This AQL filters the list of all Hardware, to only include items where the current Reporter is set as the Owner.

⚠️ In case of Portal-Only-Customers: In this case, you'll need to adjust your 'Filter work item scope' to: 

"Owner" LIKE ${reporter.label} OR "Owner Displayname" LIKE ${reporter.label}

Bare in mind that users who have permission to 'report on behalf of' can change the Reporter in the request form, and as such get someone else's Hardware as selectable options. This is desired in case of support agents having to create requests for a customer. But in other scenario's you might want to restrict who can 'raise on behalf of'.

Finishing it up (screen, request)

We have now tackled the core elements of this solution. All that remains is to ensure that the 'Hardware' field is added to the screens for the Work Item Types where it is relevant. And add the field to the Request forms where customers need to be able to select it on the portal.

And there you have it! Your customers can easily select their own devices when submitting new requests.

[Tiago Almeida]

Hi Rik,

Thank you for the write-up for this very useful use case. 

Unfortunately, as you mention, for this to work, users need to have Atlassian accounts within the site, as this does not work by referencing the request's reporter if they only have a portal-only account.

For sites with many thousands of users and hardware objects, this means maintaining some sort of automation workaround to link objects, creating and/or merging portal accounts and Atlassian accounts, as this does not work with simpler portal-only accounts.

I encourage everyone to vote for the suggestion to expand the available filter scope: https://jira.atlassian.com/browse/JSDCLOUD-10185

Thanks!

[Rik de Valk _Brainboss_]

Thanks @Tiago Almeida . I added some bits 'In case of portal-only-customer' with a potential work-around for that! I'll make sure to vote for the suggestion 😄. Have a nice day!