Reminder - Changes coming into effect in Assets for Jira Service Management

[#1]

Hello Atlassian Community,

Last year, we announced a number of changes that would come into effect for Assets in Jira Service Management Cloud (most of them as of 30th of September 2024). We have delayed rolling out some of these changes, to allow more time for Assets customers to adjust if needed.

As of February and March 2025, these changes will now begin to take effect as we roll out improvements to the underlying Assets platform.

This is a reminder to all Assets customers to review these changes, and make any adjustments required to your Assets data and workflows. Doing so will allow us to roll out performance and reliability improvements to your sites as well other planned features and enhancements. In particular, if your Assets data exceeds any of the limits listed below, we will be unable to proceed.

New limits

• A maximum of 120 attributes per object type.

• A maximum of 2 unique constraints on attributes in an object type.

• For URL, Email and Select attributes:

  • A maximum cardinality of 50 for attributes with multiple values.

  • A total of no more than 2700 characters across all values within an attribute.

See this article for a complete list of limits in Assets for Jira Service Management, Cloud.

Changes to AQL

• It will no longer be possible to use order by on an attribute of a linked object using dot notation. For example order by Laptop.CPU will no longer be supported.

• Using dot notation(.) in the context of an import mapping will no longer be supported. Note this has no effect on use of dot notation(.) elsewhere.

• The connectedTickets() function will not be supported when nested within the inboundReferences() or outboundReferences().

• Project, Repository and Opsgenie Team attributes will no longer support partial match searches using the like, startsWith and endsWith operators

• TheendsWith operator will no longer be supported for users and groups attributes.

Changes to features

• Unique constraints will no longer be supported on attributes with a maximum cardinality more than 1.

• Unique constraints will no longer be supported on TextArea attributes.

• Data locators that reference specific array indexes (for example company.region[0].id) will no longer be supported in JSON import configurations.

Changes to the public REST API

• The summable attribute is longer a supported configuration option on the following endpoints:

  • /object (response)

  • /objectschema (response)

  • /objecttype (response)

  • /objecttypeattribute (request/response)

• The objectAttributeExists attribute from the ObjectTypeAttribute response payload will be removed across all endpoints.

• The removable attribute from the ReferenceType response payload will be removed across all endpoints.

We apologise for any disruption this may cause.

All the best,

Justin King
Senior Product Manager, Jira Service Management

[Dirk Ronsmans]

Hi @Justin King ,

Looking at the changes the one thing I'm wondering about is 

• Using dot notation(.) in the context of an import mapping will no longer be supported. Note this has no effect on use of dot notation(.) elsewhere.

Does that mean I won't be able to use e.g.

Product.SerialNumber = ${Product} 

in an import mapping? Is there a specific workaround for this?

This would for example be if I have an import of devices that have a Serial Number in the Source which I would need to map on a (not label) attribute of (in this case) Product as a Reference?

[Justin King]

Hi @Dirk Ronsmans 

Would you mind helping my understand your example in a little more detail? What I'm not quite following is why the SerialNumber that is the primary identifier in the data is not an attribute on the object type you are importing into. 

Thanks!

[Dirk Ronsmans]

Hi @Justin King ,

Let me give you a better example which might show the use case, keep in mind I'm making this up as I go but this could reflect a real world case (just trying to make it generic enough):

Object Type 1: Person (coming from some HR system)

Attributes: First Name , Last Name, DOB, EmployeeID , email, 

Object Type 2: Mobile Phone (coming from a Mobile Device Management System)

Attributes: Serial Number (unique Identifier), IMEI, Owner (which could contain the employeeID or the email), Subscription, ... 

Now when I'm Importing my mobile phone devices I'd like to link them to the owner of the device through the EmployeeID. Meaning in my attribute mapping of the mobile devices I would set a AQL similar to: Owner = ${Person.EmployeeID} to create the reference link or if the source contained the email of the person perhaps also Owner = ${Person.email} to create the link.

If I were to use just Owner = ${Person} I guess that would default to the Label of the Person object type?

So unless I'm missing something I don't see a way without the dot notation in the AQL to map the import source of the mobile devices to something else than the label of the person?

I hope this makes sense :)

[Justin King]

Thanks for that Dirk! 

In this case I don't believe you will be effected. In your import mapping for the Mobile Phone object type the configuration would be:

• Data source field: owner (assuming this is the name of the column in your import CSV)
• Destination attribute: Owner
• AQL: EmployeeID = ${owner}

Remember the AQL listed there is executed against the object type being referenced in the Owner field (in this case thats Person). 

This will result in the Owner attribute on the Mobile Phone object being set to the Person object with an EmployeeID matching whats in the import data.