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. 

[Kyle W_]

Why is unique constraints being restricted?

[Mathew Lederman]

Awesome, so we're removing functionality from an already crippled tool? Are you able to share the benefits or features this removal is expected to bring?

[Kevin Thibeault]

What are the unique constraints for an objectType?

[Jonathan Ryan]

Hi @Justin King - can you explain why unique constraints are now limited to one per object?

[Kyle W_]

@Justin King additionally, if you are restricting a feature(s) that is being actively used:

1. What are you replacing it with?

2. What are you offering as a monetary discount if not the above?

3. Why are you not giving us quick access to a report showing where/what/how that feature is being used since you are putting the onus on your customers to find and remove the implementation of that feature?!

4. Do you all think these things through before making decisions?

[Ricardo van Aken]

@Justin King 

Can you please give an example of / more explanation for:

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

I received an email about this holding up updates to our environment. However I have trouble finding out where I am "breaking" this new rule, as everywhere I look it seems I can't find it what needs to be adjusted. As Kyle W_ points out in his item 3, is there a report available on how to locate this?

[Julia Ackermann]

Hi, 

we've received a mail stating we are exceeding the 2 unique constraints limit. Is there a way to find out which object types have too many unique constraints besides checking every attribute configuration on every object type? Seems like a lot of work...

[Heather Weatherholt]

I am confused as well.  I am not 100% sure what unique constraints are but using context clues, I am assuming it is either where I have created drop-down fields referring to another schema of standardized entries to limit what others put in that field or they are related to data validation rules that I have put in place to limit what someone can enter into a field.  Also, when you say "A total of no more than 2700 characters across all values within an attribute", does that mean all of the fields for the attributes combined can only contain 2700 characters total regardless of how many fields there are, for example, I could have 1 attribute field about an object and it can contain a total of 2700 or if I had an asset schema that had 120 fields of information I can only put 22.5 characters in each field?  Also, how do I figure out what assets\attributes are issues so I can get it straightened out?

[ankur_patel]

I am confused too. Need some help in understanding the unique constraint and how to identify them. 

[Cam Browning]

As with several other commentators, can Atlassian please provide an explanation of how organisations can determine which attributes have >2 unique constraints in Assets. 

Atlassian isn't seriously suggesting that organisations manually check the configuration of every single attribute in every class in every schema to ensure that the unique checkbox has not been selected?

Our organisation has 1700-odd attributes configured. This will take considerable time to review.

[Juan Agustin Lemos]

2 restricciones únicas en los atributos de un tipo de objeto que significa esto lo pueden explicar

[Govind Vijayakumar]

It would be great if Atlassian could provide a guide on how to find the objects with more than 2 constraints. Quite a cumbersome process to go through each asset to find this. Even after doing that I couldn't find anything relevant to this. 

Edit: Contacting the support by submitting a ticket is the easiest way to get those objects. Support is very responsive. 

[sciencecovskij]

To those who are still struggeling with the "unique constraints" problem - maybe my solution helps: https://community.atlassian.com/forums/Jira-Service-Management/Total-unique-constraints-per-object-type/qaq-p/2966858

[Mahender Kumar]

Another way of Finding Unique attributes is by making a get request https://api.atlassian.com/jsm/assets/workspace/{workspaceid}/v1/objecttype/{objecttypeid}/attributes and search for "uniqueAttribute": true in the JSON

[sciencecovskij]

@Mahender Kumar This is basically what I do in my programmatic solution. The reason I first go through the object types of a schema and then the attributes of each object type is that I like to first determine the IDs (and names) of the object types for the program so that I can use and output them directly in the attribute query. But maybe I misunderstood a part of the REST API docs and could have made it simpler. 

[Justin King]

Hi everyone.

The reason for this new limit of 2 unique constraints per object type is that the addition of large numbers of unique constraints is a contributor to performance problems. This is not something specific to Assets, but to all database systems. We are aiming to ensure we can offer high performance while also allowing enough flexibility with features such as unique constraints to meet the needs of the vast majority of use cases. I understand there may be use cases where more than 2 could be useful and we'll continue to evaluate whether its feasible to increase the unique constraint limit over time. 

On the issue if locating your attributes that currently have unique constraints. Thanks for the feedback, I can see how in some cases this could be challenging. We are evaluating how we can help with this and I'll post an update on that soon. 

All the best, 

Justin