Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
Level
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How Should I Structure My Objects In Insight?

Hello again! I hope you’re keen to learn more about Insight. Following on from my previous article where I shared some advice on how to decide what should go into Insight, I’m back to discuss how to structure your objects. In this article we’ll take a look at three top pieces of advice for modelling your data. Again there’s no wrong or right way to this but there’s things to consider to make your life easier.

If you have anything else to add please comment below and share with the community.

 

1. Split data into logical object schemas

All of your data doesn’t need to go into one huge object schema. We recommend having multiple object schemas based on the use of the data or the owner(s) of the data.

Insight and Jira don’t care which object schemas contain what data. The admin just points a custom field at the data it needs, whatever schema it’s in. And custom fields can pull and push data into multiple object schemas from one issue. Links between objects in one object schema can be made with those in another and queries can be run across different schemas. Object schemas are mainly there to make our lives easier rather than for Insight itself.

Breaking your data down into different object schemas is both more user friendly and easier to maintain. Teams such as the finance or HR departments who may need some information from Insight, don’t need to be bombarded with information they don’t care about. It’s also easier to ask one team to do a regular check of data quality on one object schema, than it is to ask them to check only certain parts of one large object schema.

And finally, each object schema can have its own permissions so if you have sensitive data you can keep that hidden from certain users.

 

2. Federate your data

If you have a perfectly usable database or source of information somewhere and there are processes already in place to keep it updated, the data doesn’t need to be moved into Insight. Instead it’s likely better to create a copy of the relevant data using integrations and have those integrations run on a schedule to update the Insight information.

Insight comes with a number of importers and integrations (not all are available in Cloud right now but we’re reviewing the integration needs now) including CSV, JSON, LDAP, ServiceNow, Device42, AWS, Azure, Google Cloud, and more. With these importers and integrations, the information you need to make decisions can be made available in a Jira issue/Insight itself, but you’re not maintaining two separate copies.

A really common example we see of this is people using the LDAP importer to sync Insight with the Active Directory. Now you have all of your users easily available and you can run the sync periodically to keep it updated.

Sometimes people will create separate object schemas for this imported data, other times people integrate them into bigger object schemas. If the data is going to be used in multiple places then it makes more sense to have it as a separate object schema.

With the integrations, we recommend not bringing every bit of data available into Insight as per the previous article. You can decide what does and doesn’t make it into the object schema when setting up the integration. You also shouldn’t update this data within Insight itself unless you also push that change to the original source of data otherwise you’re going to end up with conflicting data.

If there’s not a pre-built integration available then you some other options. The first is to export the data as a CSV/JSON file periodically and have the Insight CSV/JSON importers bring them in on a schedule. Alternatively, you could create a relatively empty object and give it a URL attribute that links to the other database where more information can be found. This option is good if you just want agents to be able to view the information and don’t want to search or report based on it.

 

3. Avoid reusing the same attributes everywhere

If an attribute is used in many places and has the same repeated values then often it makes more sense to make it its own object type. For example vendor. You could have an attribute called vendor for the object types laptop, phone, printer, monitor etc. And for each object you would need to type (or import) the vendor name for that particular laptop or phone.

This is fine, but it’s more efficient to have an object type called ‘Vendors’ and set each vendor as an object. This is for a number of reasons:

  1. You may want more than just the vendor name. Maybe you want other information related to the vendor such as support contact number or links to contracts. You don’t want to have to repeat this for every laptop and every phone. Just have it once and link to the vendor object. This also helps if you want to do elements of vendor management within Jira too.

  2. The vendor will always be standardised now, meaning reports are easier to run. If you wanted to check the number of incidents vs vendor you can be confident you’re not missing something because someone wrote Micrsoft or Aple.

  3. If the vendor rebrands or needs to be changed in some way you only need to update it in one place.

Vendor is just one example but others include business importance levels, deployment environments, departments, locations etc.

 

 

That’s all for my tips on structuring your data. Do you have any more? Or any questions? Comment below!

 

4 comments

@Charlotte Nicolaou  

I have read both of your articles, and I find them very interesting, so first of all I thank you for writing them.

I have been using Insight in version for Jira server and I think it is the best CMDB plugin around at the moment.

Then I tried to use it for a project, recently, but in the version for Jira cloud and I realized among the many limitations of two in particular: a) that I can have up to 10,000 assets and b) that I can not do exactly the same queries that can be built with the server version. Maybe I did something wrong ? Or is it like this ?

And if so, I hope Atlassian will bring very soon the cloud version of the plugin to the same functions of the server version.

Like Kate Clavet likes this

Hi @Kalos Bonasia 

that's great to hear! Thank you. I'm glad you're finding these posts helpful. If you have any suggestions for other topics please let me know and I'll see what I can do. 


Thank you for flagging up your pain points with Insight Cloud. I can assure you we're working hard to improve both the areas you've mentioned :) 


When you say queries do you mean when filtering objects for the Jira issue fields or searching Insight itself for certain objects? 

The number of objects in Cloud should be more like 60k rather than 10k but it depends how many attributes you have, how it's set up etc. Given you're already using Server it's probably best to wait for a later version of Cloud rather than trying to optimise for the current version. 


Hello, Do sample object schemas, such as the ones that you describe, come out of the box with the software, or can we get them somewhere? It would be great--and save tons of time--if we had somewhere to start, with the most common schemas, rather than from a blank slate. 

Hi @Mary Beth Snapp

For Insight for JSM Data Center, we do have a number of templates including one for ITSM. 

For Insight for JSM Cloud, we currently don't have any templates. They are on our backlog to add, but I'm not sure when you can expect them. 

I actually plan to write a Community article next week on this very topic. My plan was to go through the Data Center ITSM template and write about the different object types and attributes that are included. I don't know if that would help at all? I figure something is better than nothing until we get a template into Insight Cloud. 

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Jira Service Management

ThinkTilt is joining the Atlassian Family!

This morning, Atlassian announced the acquisition of ThinkTilt , the maker of ProForma, a no-code/low code form builder with 700+ customers worldwide. ThinkTilt helps IT empower any team in their or...

156 views 9 10
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you