Assets/Jira Automation: How to copy custom user picker field value to an Assets field?

[Ashley Honeycutt]

In a Jira Software project, on a "create issue" screen, I have a custom user picker field. 

On the "view issue" screen for the same issue type in the project, I have an Assets field that captures a user and lists attributes associated with that user.

All users in the instance can submit issues to this project, but only one group can view the already created issues. It's not appropriate for most users to view the attributes outside of this team but they do need the ability to select a specific user.

Due to this, I would like to create an automation rule that copies the value in the user picker field to the Assets field. 

Any thoughts on this are greatly appreciated! Thank you!

[Tobias H]

Hi @Ashley Honeycutt!

I assume that the User Picker field is a custom field you created?

Do you create the asset with the request, or do you wish for it to be added to an already existing asset?

Why I'm asking is depending on what you want to accomplish, the automations will look a bit different.

[Ashley Honeycutt]

Hi @Tobias H

Correct, the User Picker field is a custom field that allows selection of any user in the instance.

The Assets field is intended to display Attributes related to that user so the team using the project has them available for reference on the view screen of issue after it's created. However some of those attributes are confidential and shouldn't be viewable by the reporter of the issue, which is why I think we need that separate User field that the Reporter can use when creating the issue.

[Tobias H]

Thank you for the additional context!

Do the reporters have JSM licenses and access to Assets?

Otherwise I believe it should be enough to let the user pick their own asset directly, and only decide what can be seen in the portal view via the context values

The first field decides what can be searched and seen within the portal view
And the second field decides what is visible to agents from within the issue view

So in my case below, users can search for their IT hardware by either the IT asset tag, the model of the device or by searching their own name.

The selected devices will then be displayed inside the issue to agents with the information: Who it's assigned to, the status of the device, the model, when we believe it has reached end of life and how many times the device has been previously leased to other people.

Have you tried doing it like this? And in case you have and it didn't work, what was the issue?

[Robert Hook]

@Ashley Honeycutt 

So as an example, you have an Assets object type called Employees. And the Employees objects have attributes you want to display in an issue field called Requesting Employee, which is an Assets object field.

You could use a Trigger for your automation for Field value changed, then select the User Picker field, and either "Any changes to the field value" or "Value added" as the change type. This should kick off the automation when something is added or updated in the User Picker field. 

(Side note: I often find I need to insert a Re-fetch issue data step after the Field value changed trigger for it to work properly.)

Next, you would have an Edit issue step in your automation. Select the Requesting Employee Assets object field in the dropdown list and update it with an AQL to match the User Picker field. Something like:

objectType = Employees AND Name = "{{issue.User Picker}}"

In that AQL, the assumption is that your Employees objects have a Name attribute that you can use to match with in your query.

You can also do this with a Lookup objects step in the automation followed by an Edit issue step that updates the Requesting Employee field with {{lookupObjects}} , but that seems like overkill when you should be able to accomplish it in one step.

The above example AQL may not work for you and may have to be tweaked depending on how you have your Employees asset object types set up and what the attribute types are for the Employees objects. It is difficult to write a proper AQL without having that information.