Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

We're setting up data certification process for CMDB and Assets in JSM and looking for best practice

Nathan Gifford
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 7, 2025

We are in the process of formalizing our CMDB and Assets in JSM. For Assets we will be checking the import from InTune against what appears in JSM and the data on the assets themselves. Once that is complete, we will be setting up a data certification process for our CMDBs covering everything else. 

Before we begin, we are curious if there are other companies that might have done something like this in the past and were wondering if you could share best practices or lessons learned.

1 answer

0 votes
Christopher Yen
Community Champion
October 10, 2025

Hi @Nathan Gifford , welcome to the community!

I think some lessons learned I've had around setting up CMDB's in general is to have a clear business use case which will determine what attributes/fields are useful. I think usually the more problematic CMDB's I've managed are due to inheriting data from a previous inventory system where we're unsure of why certain fields exist and add to the overhead of keeping the data fresh, so if possible better to start fresh and document the reason and use case behind each attribute when setting it up. 

If using an InTune import and all fields are updated via InTune then I think that's a good approach, if there are attributes where it needs to be manually filled out make sure to have a well documented process and RACI of who is accountable / responsible or else more than likely the data will become stale and unreliable which leads to lower confidence in the overall CMDB. 

Specifically for JSM Assets what we've experienced is it's not really geared for workflows within the CI (at least when we set it up last year), I believe currently only global automations are available for JSM assets and it's been clunky and easily hits rate limits when working only within a CI. Things like if an agent marks a computer as "in stock" they'd like to see it clear the assigned user automatically have been difficult because there are no "workflows" in assets and I think we couldn't find proper triggers with the global automation so we ended up having to do asset automations/workflows from JSM work items which I believe maybe was what Atlassian intended. So we have tickets with workflows that assign an CI to a user, onboarding, offboarding that will perform updates on the asset linked in the work item rather than having agents go directly to the CI to make attributes. There may have been new features or automation triggers since I've last looked at it so that may be worth exploring again but that was one of the main limitations we had to work around when setting up our CMDB

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events