Bulk Update Jira Service Management Assets from Excel

Why this needs more care than an export

Exporting is read-only by nature: get it wrong and you re-run it. Writing back to a CMDB is not. A bulk update that misreads a column, matches the wrong object, or tries to overwrite a system field can leave your asset register worse than before you started. A safe bulk-update path needs to know exactly which object each row refers to, refuse to touch fields it shouldn't, and show you what it's about to change before it changes anything.

What matching the row to the object requires

Every row needs to resolve to exactly one existing object, and the only reliable way to do that is an object key column: the same key Assets already uses to identify that object (for example, a value like ASSET-1234). Matching on a name or description instead risks matching the wrong object, or several, if names aren't unique. A row with no key, or a key that doesn't resolve to a visible object of the expected type, should be skipped and flagged, not guessed at.

What should never get written automatically

• System and read-only attributes, like created and updated timestamps, which Assets manages itself.
• Values pointing at another object (reference attributes) that don't resolve to a real, visible object of the expected type.
• Select or status fields set to a value that isn't one of the schema's actual defined options.
• Empty cells, which should mean "leave this attribute alone," not "clear it."

Reviewing before anything commits

1. Map each spreadsheet column to the object attribute it corresponds to.
2. Run a dry run: for every row, see the object it resolved to, and a before/after value for every attribute that would actually change.
3. Check the rows flagged as errors or skipped, since those are usually a mapping issue or a value that doesn't match an allowed option, not a real intended change.
4. Only after reviewing the diff, commit the update.

What this doesn't do

This updates existing objects matched by their object key. It doesn't create new objects from spreadsheet rows that don't match anything, and multi-value reference attributes are out of scope, since a single cell can't unambiguously represent a list of linked objects. For enriching or correcting objects that already exist in Assets, matching by key and reviewing a diff before writing covers the job without either of those.

Getting the workbook to edit in the first place

See how to export Jira Service Management Assets to Excel for how to produce the workbook this update process starts from.