CSV Import for updating reference fields - Team, Group & Space

Question

I'm going round in circles, hopefully someone can give me the silver bullet! I am trying to update reference fields on the new services system schemas: Software Registry > Technical services > Applications Software Registry > Technical services > Software Services I'm using CSV import to update attributes. Anything that's just a text entry or status etc. updates fine. However, any reference field, like Team, Group or Space (for Change Management Connected Space) won't update. I've tried the various formats available for each - for Teams for e.g. ari:cloud:identity::team/1be45cae-262e-48ea-b4f1-218e13bc9ed1 <- This is what shows in the export where I have manually selected a Team 1be45cae-262e-48ea-b4f1-218e13bc9ed1 <- confirmed this in the URL for the Team Team Name <- plain text name throwing things at the wall... Each time a new file and creating a new import mapping - hopefully to avoid any caching issues. Columns in the CSV are labelled exactly as the attribute field names, appropriately mapped in the import mapping etc. I have not used the 'automagic' mapping - I manually create each time as it seems to want to treat everything as text. When I import I either get no update at all or a newly created object type (probably more to do with which boxes I've ticked on the import settings.) I get no failures on the import report and it shows me it's 'updated' the correct number of objects - but when checking it's created them in a new schema. The CSV I'm using for import was exported from the schema, so it has the Keys listed and I'm using that Key + Name as the identifier (read in an Atlassian article somewhere.) I'm really struggling to find anything other than surface-level info in the official docs. Hoping that some guru can help me out here… It's probably something really obvious. Cheers, -Jeff

Arkadiusz Wroblewski · Answer

Hi @Jeff Gibson

Also check that your import targets the existing Software Registry object type and not the legacy Services schema with disabled automatic object-type creation.

For a single-object test, set Missing objects and Empty values to Ignore to prevent unintended changes.

https://support.atlassian.com/assets/docs/create-objects-from-data-using-object-type-mapping/

Atlassian advertises CSV imports for new Services schemas, but I couldn't confirm whether the importer supports these three system-managed reference attributes. If the existing object updates correctly but they remain empty, ask Atlassian Support for clarification.

https://community.atlassian.com/forums/discussion/3255620/services-assets-one-source-of-truth-with-two-new-purpose-built-schemas

Best,

Arek🤠🧙‍♂️

Mihai_LeanZero · Answer

Hi @Jeff Gibson, These three aren't read-only. On a test site the Assets API took each of them as a full ARI and rejected names and bare IDs. Owner team takes ari:cloud:identity::team/, so the value from the export was right and the rows most likely never matched the existing objects. Change approvers takes ari:cloud:identity::group/, with the id from the group's page in admin.atlassian.com. Connected space is the linked Jira space, and its ARI still says project: ari:cloud:jira::project/, with the cloud id at /_edge/tenant_info on the site. These are ARI fields, not object references, so the Label = ${Locator} lookup doesn't apply. The cell just holds the ARI. Karpets's identifier point is still the first fix. Objects landing in a new schema usually means the import targets the wrong object type. I tested the API, not the CSV import. Failing that, the experimental Services API "Update a service" call sets all three from plain IDs: https://developer.atlassian.com/cloud/jira/service-desk-ops/rest/v3/api-group-services/

Artyom Karpets _ArtUp Labs_ · Answer

Hi Jeff, two things in your description line up with known causes, so I would change those before trying more reference formats.

* Identifier. You wrote that you use Key + Name. Atlassian's KB on updating objects through CSV says the importer recreates objects when it cannot match rows to existing ones, that Label is normally the identifier, and that Key is a poor choice, because keys are regenerated on import. Exactly one attribute must be the identifier. A new object type or a copy of the objects in another schema is what a non-matching identifier looks like. Set the identifier to the label attribute (or another unique non-empty column) and test on a two-row CSV.
* Reference attributes. In the attribute mapping, the Object Mapping (AQL) field decides how a cell is turned into an object: "Label = ${Locator}" for one value, "Label IN (${Locator${0}})" for several, with multiple values separated by ||. So the cell should hold the target object's label, not the ari or the key. You already tried the plain name; without that AQL in the mapping it is treated as text. If the label attribute on that type is called Name, write "Name = ${Locator}". The referenced objects must already exist in the destination schema.

One caveat: I have not tried this on the new Software Registry service schemas. Your export shows Team as an ari:cloud:identity::team value, which suggests Team (and maybe Space) there is a special attribute type linked to Atlassian Teams rather than an object reference, and the importer may not resolve it this way. If a clean test with a label still leaves those fields empty, I would raise it with Atlassian Support.

Sources: "Update Objects in JSM Assets Cloud via CSV Import" and "How to import Assets object types with attributes referencing existing objects" (support.atlassian.com KB), "Create attributes and references from your data".

Drafted with an AI assistant and reviewed by me