Append a value/reference object to an existing Assets attribute via automation

[Robert Hook]

We have several cloud software portals where we manage user access to products that do not allow SCIM provisioning to tie their access directly to their org account. We have an Assets schema for software where we track the license assignees for those products so when a termination or other deprovision action comes in, Jira automation can tell us in which of these products we need to disable access. Since humans sometimes take shortcuts or don't follow SOPs, the Assets object does not always get updated when a user is added or removed from a software portal outside of onboarding/offboarding, so that list is not always 100% accurate. We also use that Assets schema for an at-a-glance view of licenses we have available and licenses we have filled instead of going to each individual portal to check every time. So maybe not 100% the best process, but it is what we have. 

The Assets object with License Assignees attribute as a reference object to user object types in a schema called PEOPLE:



I can build a scheduled automation to periodically pull a user list from some of those portals via API, but I am struggling with how to automate adding or removing a user as a License Assignee in the Assets object after I get that information. What I have so far is shown in the screenshot further down below. The off-screen part is the web request that pulls user information from one of the portals in this format:

I split that list out in a for each branch to compare to the users we have as License Assignees for that software in Assets. This all works successfully.

What I can't figure out is how to update the Assets object with any users not already listed. (The Add comment step at the end is just a placeholder for now.)  Since I am already in a for each loop, I can't branch on an AQL inside of it to edit the object with currentusers + newuser. I could not find a way via Jira's API to append another user as a license assignee (which is not to say that it is not possible...I just didn't find an answer).

I can't tell if I have just gone down a bad logic path with this automation architecture in the first place, or if there is an answer within or closely related to the structure I built.

[Andrea Robbins]

This is a common issue and the resolution is documented here:

https://support.atlassian.com/jira/kb/how-to-append-list-of-objects-to-a-reference-assets-object-attribute-using-automation/

---

However, I always design around this, so this never happens. I create a User Assignment object type that has the Assigned User & the Assigned Software (application or product). This can produce a lot of objects, so what I do in my automations is on the assigned app object, I have a boolean attribute called "Managed by Okta/IdP", meaning when the user's IdP groups are removed, does it also remove access to this app. Only if this is set to false does it create this user assignment object.

---

You could also have a list of applications attribute on the user, but you run into the same issue, but it's not as great of an issue because (in theory) you'd have less applications assigned to a user than users assigned to an application.

Hope that helps

[Robert Hook]

Thanks @Andrea Robbins . I was hoping to avoid creating a work item to accomplish this, but it appears that is not possible with the linked article.  I appreciate the reply. For the most part, the apps that would leverage this have a pretty small footprint - the larger ones already are federated/SCIM provisioned and have their info readily available via other means. I'll have to play around with your other solution to see if I like it - thanks for sharing that!

[Graham Moore]

Hi Robert,

Assuming I'm understanding the process correctly (and that is a big assumption at 5pm on a Thursday!), does this work?

Since you already know the user that is missing, right after your "Lookup objects From Software" step (before the comparison), add a new Create variable step:

• Variable name: CurrentAssignees
• Value: {{lookupObjects."License Assignees".Key.asJsonObject("value")}}

This captures the current assignee list in the right format for use in the request body. Storing it in a variable can handle any instances where a software object currently has zero assignees (which would otherwise break the JSON below).

Then replace your placeholder 'Add a comment to work item' with a Send web request action, with a PUT back to the software object, with the list of current assignees appended with the new user:

{
"objectTypeId": "{{lookupObjects.objectType.id}}",
"attributes": [{
"objectTypeAttributeId": "YOUR_LICENSE_ASSIGNEES_ATTR_ID",
"objectAttributeValues": [{"value":"{{AssetsUserObject.Key}}"}{{#if CurrentAssignees}},{{CurrentAssignees}}{{/if}}]
}]
}

 Fair warning, you might need to tweak that JSON, I haven't tested this! 

[Robert Hook]

Thanks, @Graham Moore 

I played with that JSON for a long time and couldn't figure it out either. It errors out with the objectAttributeValues - it doesn't seem to want to pass multiple values inside there. It always resulted in an error similar to:

{"errorMessages":[],"errors":{"rlabs-insight-attribute-1892":"PEOPLE-3962, PEOPLE-3601, PEOPLE-3864 is not valid Object id or key"}}

[Graham Moore]

Hi Robert,

Doh, the issue is that it isn't an array, so it's treating each value as one big combined value instead.

The most robust way around this is to create a forge function to act as the middle-man (since we can't nest loops into a branch), something like:

• Automation calls the forge function, newUserKey + softwareObjectId
• The forge function GETs the current Software object from Assets, reads existing assignees, adds the new user, and PUTs the complete list back

Otherwise, without using Forge, you could begin building the array outside of the branch but then that would require the portal to be your source of truth (i.e. any assignees added to Assets directly wouldn't be accounted for). 

The good news is that you can easily write a Forge function with Rovo CLI if you aren't already familiar with building in Forge!

[Andrea Robbins]

You could always do a lookup object so it’s the object existing values plus the values you want to add:

key in ({{object.attribute}}) OR Name in (list of names here)

 then edit the attribute setting with {{lookupObjects}}

I will see if I can find an automation rule I have done that does something like this