How Should I Structure My Objects In Insight?

[#1]

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!

[Deleted user]

@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.

[Charlotte Nicolaou]

Hi @[deleted] 

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. 

[Mary Beth Snapp]

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. 

[Charlotte Nicolaou]

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. 

[Adam Bosen]

Please, this would be an excellent resource, for those of us starting out with Insight configuration. I for one would find a community article based on the ITSM template in Data Center extremely helpful right now :) 

[Charlotte Nicolaou]

Hi @Adam Bosen 

I actually did publish one recently and it can be found here: 

Template walkthrough 

It takes influence from the Data Center template but I split some of the objects into different schemas as, in my opinion, it makes it significantly easier to manage long term. 

It's Cloud focused as I'm shamelessly trying to boost it with key search terms. But the content is relevant to DC too. 
The one exception is that DC doesn't have the 'Services' object schema that I reference in that article. But there's no reason you can't create your own Services objects in DC. 

I hope that helps :) 

[Karolina Dylewicz]

Hi @Charlotte Nicolaou , 

I'm looking for information about the checkbox option 

"Pass all attributes to child object types."

I don't understand the difference or the consequences between checking it and not checking it. Therefore, I can't decide which option will be better for my scenario.

What are the possible scenarios in which each of them will be more beneficial? 

I've only found this article which says how to do it. 

https://support.atlassian.com/jira-service-management-cloud/docs/allow-attributes-to-be-inherited-by-object-type-children/

Could you please explain it?

[Tiffany J]

@Karolina Dylewicz

 @Charlotte Nicolaou 

Yes I would love the info about the scenarios from Karolina above as well.

Thank you for your help so far.