Is there a template for Insight Cloud?

Hi Community,

Since Insight was recently released as part of Jira Service Management Premium and Enterprise plans, this question has come up a lot.

Currently, there isn’t a pre-built template for Insight in Jira Service Management Cloud but please be assured it is on our radar!

In the meantime, I thought it would be useful to have this community article to walkthrough an example Insight setup for asset and configuration management. That way you can see the types of objects and attributes you could include so you’re not starting from nothing.

This is only a suggestion. We highly recommend you tailor your object schemas, object types, and attributes to your organization. Every company is different and so it’s impossible for us to say exactly what you should include.

This article will assume you have knowledge of how Insight is structured. If you’re completely new to Insight, please take a look at either of these resources first to familiarise yourself with how Insight is structured..

Right, let’s dive into this example setup! Some of these schemas will be quite empty for the purpose of this demonstration as we’re focusing on the structure.

Object schemas

Our advice is to split your data into different object schemas to make it easier to maintain and define which employees are responsible for periodically checking the data is up to date.

In this example, we have four objects schemas each with their own set of object types.

Community Post - Object Schemas.jpg

 

Company Information schema - stores information about the company’s offices, employees, suppliers etc.

Insight Discovery schema - stores information about the IT infrastructure running the company’s services. Most of these objects were collected using the Insight Discovery network scanner.

IT Employee Assets schema - stores information about the hardware given to employees.

Services schema - syncs with Jira Service Management services so you can link the services to the underlying infrastructure that supports them.

Now we’ll look at each of these schemas in turn.

 

IT Employee Assets schema

In this schema we have the physical hardware assets we want to track. But also another set of object types that stores the hardware models the organization supports and provides in their hardware request catalog. These supported hardware model object types can be selected by an employee when they request new hardware through Jira Service Management requests.

Community Post - IT Employee Assets Schema OTs.png

In this example we have included supported mice and keyboards in the supported models so employees can request them. But we don’t track the actual mice and keyboards as they’re too low value to require it.

This schema could be extended to include software that employees use and might want to request, and the licenses behind them.

Note: the Hardware and Supported Models object types are just placeholders. No objects would be added to these but it’s easier for us humans to navigate the schema.

Let’s look at two object types in detail.

 

‘Laptops’ object type

Community Post - Laptop Attributes.png
Community Post - Laptop Object.png

Here you can see the attributes (denoted by a $ in this article's text) we have for the ‘Laptops’ object type.

Ones to highlight are $Status, so we can track our laptops from purchase to retirement, and two object reference attributes  $Owner and $Model. The $Owner attribute creates a reference between a laptop object and another object, in this case an ‘Employees’ object. ‘Employees’ is another object type found in the Company Information object schema that we’ll look at in the next section.

The $Model attribute links to the ‘Supported laptops’ object type in this same IT Employee Assets schema. If we want to see the memory, screen size etc of a particular laptop, we can just click on the linked ‘Supported laptops’ object instead of listing these specs for every single laptop we have.

‘Supported laptops’ object type

Here are the attributes for the ‘Supported laptops' object type. You can see we have statuses for these of ‘offered’, ‘coming soon’, or 'previously offered’ to use this object type as a hardware catalog. This $Status attribute means that if we link an Insight Custom Field to this object type for people to request hardware, we can ensure only currently supported hardware is displayed using a filter. But we can still retain a record of hardware that is coming soon or we previously offered.

Community Post - Laptop Model Attributes.png
Community Post - Laptop Model Object.png

Another thing to point out is that this object type has a $Manufacturer attribute which links to the ‘IT suppliers’ object type in the Company Information schema. We could have a ‘Suppliers’ object type within this IT Employee Assets schema but other schemas may have suppliers too so in this example we have centralized all the suppliers in one schema.

If we go back to our actual laptop object and click on ‘Object Graph’ we can get the view below. We can see the laptop and technical details, location, and information about who owns it. This graph is generated based on the referenced attributes that link to other objects. These graphs can be viewed for any object, or for an object type, to see how everything is related.

 

Community Post - Laptop Object Graph.png

 

Company Information schema

This schema is designed to be a centralized location of company information that may be relevant to other object schemas. For example, employees can be the owner of objects in the IT Employee Assets (e.g. a laptop and phone) and they could be owners of objects within the Insight Discovery schema (e.g. of a host or application.) if we wanted.

Community Post - Company Info Schema OTs.png

 

Note: you must go to object schema > configure > general and check the box to ‘Allow others to select objects from this schema’ to enable other object schemas to see this schema.

Let’s look at some of the object types and attributes.

‘Location’ object type

‘Location’ is a very simple object type where we can document our offices and other important sites. These can then be linked to employees, hardware etc.

If you are interested in modelling your locations in more detail for facilities management, I recommend reading this series of community articles by @C_ Derek Fields .

Community Post - Location Attributes.png
Community Post - Location Object.png

‘Employee’ object type

‘Employee’ is a bit more substantial with many personal attributes. Many organizations have their own tools to monitor a lot of this information so much of this may not be needed.

For sensitive information, you can set permissions on a specific object types by going to Object Type > Configure > Roles.

Community Post - Employee Object.png
Community Post - Employee Attributes.png

The ‘Employees’ object type is linked to the Jira user for the employee. By having that linked to the employee object type, when a hardware related request comes in from a Jira user, automations can be used to find that user’s Insight entry based on the $Jira user attribute, and then see all of the different objects that they own and pull them into the Jira issue if relevant.

The employee also has a $Manager attribute which links to another ‘Employees’ object. This field could be used for auto approvals. If I, the employee Charlotte, request something, then automation rules can be run to find my manager in Insight, find their Jira user name, and then set them as the approver and assigned user for my request which cuts down on the time wasted on routing issues manually.

An alternative way to do this would be to assign each ‘Employees’ object a ‘Team’ (which is its own object type) and have an assigned manager of that ‘Team’ which acts as the approver for all linked ‘Employees’.

Finally, the ‘Employees’ object type also has $Department and $Role attributes that link to other object types ‘Departments’ and ‘Job roles’. These can be used for various use cases if you were to expand your object schemas.

For example:

  1. ‘Departments’ or ‘Job Rolea’ objects could be linked to the ‘Supported laptops’ object type to say which departments/roles can request them. It makes sense for the development teams to have laptops with larger screen sizes and higher RAM than the sales teams, so with Insight Custom Fields, request forms could be configured to show different laptops based on the department/role of the requester.

  2. By having these as object types, you can do reporting based on the department or job role of the requestor. For example, you might see that more service requests per employee are coming from the marketing team than the finance team and therefore maybe there’s a gap in knowledge. Or you might discover many requests for certain software have been made from a particular department so it makes sense to add that software to the laptop image that those employees get when they start.

‘IT suppliers’ object type

There is also a section of this object schema dedicated to suppliers. We can see an example of the IT suppliers object type here.

Community Post - Suppliers Attributes.png
Community Post - Suppliers Object.png

 

We have different object types for different types of suppliers. We could, if we wanted to, have one ‘Suppliers’ object type and have an attribute within it that says what type of supplier it is. It’s completely up to you how you want to structure it. But it’s often useful to have some way to categorize your suppliers.

The ‘IT suppliers’ object type has a $Contracts attribute that references the ‘Contracts’ object type.

Note: the $Contract attribute in the IT Supplier object type has been configured to allow multiple values in the attribute. You do this by selecting the cog next to the attribute > configure > cardinality and setting what you want.

 

Community Post - Contract Object.png

 

This ‘Contract’ object type is used to just link to an external location where we can find the actual contract. We are investigating having an object attatchment feature in future.

Again, you could add this to the supplier object itself as a URL attribute type. But I wanted to demonstrate that you can have attributes that allow you to set multiple values.

Insight Discovery object schema

This is our biggest object schema and where we store details about our underlying infrastructure. The majority of this information has been brought in using the Insight Discovery. Insight Discovery will scan your network and populate an object schema with relevant information and the links between various objects.

Community Post - Discovery schema OTs.jpg

I won’t go through each of the object types in this object schema but I will show a few. You can see a full list of what object types and attributes Insight Discovery detects here.

But here are some examples:

File system

 

Community Post - File Object.png

Virtual guest

Community Post - Virtual Guest.png

Host

 

Community Post - Host Object.png

 

Metdata object types

We have also added a few extra object types to the Insight Discovery object schema under the heading ‘Metadata’.

Community Post - Metadata.png

 

These object types let us link (or tag) our infrastructure and applications with the environment (staging, production, test), importance (1-4 for example), and a category (finance, marketing, communication etc).

The benefit of having these as their own object types is that if I decide to rename the levels of business important or a certain category, I only need to rename it in one place. If I had business importance as a text attribute in other object types I would need to go into potentially thousands of objects to rename it.

You may not need these specific tags, but you can create whatever tags you do need to understand your assets and configuration items in more detail.

Services object schema

Finally, I’ll quickly cover the Services object schema. This schema is read-only and is auto-generated from what you enter as services in Jira Service Management.

Community Post - Services schema.png

The idea behind it is to allow you to link your infrastructure objects to the services that they support for better change risk analysis and incident and problem resolution. So below you can see our Billing service is linked to a Billing application which depends on some software and underlying infrastructure.

Community Post - Services Object Graph.png

Summary

This is a high level walkthrough of one way to configure your Insight database. This is just an example, if attributes or object types are not relevant to you, skip them! But hopefully this gives you an idea on where to start. 

If you have any questions or would like to suggest different ways to structure your data, please comment below!

 

13 comments

G subramanyam
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 20, 2021

Thank you @Charlotte Nicolaou for that detailed article. 

Like Charlotte Nicolaou likes this
Tim April 28, 2021

As a new Insight user, this example was extremely helpful. 

Like Charlotte Nicolaou likes this
Adam Bosen May 14, 2021

absolutely fantastic, really helped to point in the right direction, especially the linking between "Services" and insight objects. thankyou!

Like Charlotte Nicolaou likes this
Anuradha Das May 19, 2021

This is the first thing I was working on as a request to enable for our team. This has blown my mind !Its amazing .Thanks for writing this post @Charlotte Nicolaou .

Like Charlotte Nicolaou likes this
Aman Sinha June 30, 2021

@Charlotte Nicolaou Hi! We need to add more information to the services, but since the services schema is a read-only schema we are unable to add any attributes to them. Do you recommend creating another insight object type in a schema to add these services there and then add more information to it? In that case, what do we do with the original services (also displayed in the panel), which I believe would be needed while working with OpsGenie? Is there a way to make this work without having two sets of the same services?

Like Steffen Opel _Utoolity_ likes this
Charlotte Nicolaou
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 1, 2021

Hi @Aman Sinha 

That's a good question, and it's definitely on our roadmap to open up the Services schema so you can add custom attributes. 

One solution is to create a duplicated Services schema as you say. And certainly you can do that but we found it wasn't ideal when we tried it in our internal demo. It's too fragmented. 

My suggestion would to be create a middle object. Maybe called something like 'Services meta data'. You can then link this between your read-only Services objects and your underlying infrastructure. It's not the most user friendly, but it would allow you to use the proper Services in your issues, access the meta data from the issue via the object graph, and when the Services schema becomes customisable it's reasonably simple to migrate the meta data attributes from these middle objects to your Services in the Services schema.

Something like this: 


Screenshot 2021-07-01 at 09.57.20.pngScreenshot 2021-07-01 at 09.53.56.png


Hope that makes sense. 

Like # people like this
Aman Sinha July 1, 2021

Hi @Charlotte Nicolaou 

Thanks for your prompt response. I am looking into this.

 

I believe this is on your roadmap but we wanted to know by when can we expect an ITSM template for Insight Cloud to import?

 

Also, is it possible for us to get some assistance/guidance from Atlassian in developing an ITSM template?

 

Thanks & Regards,

Aman

Like # people like this
Dusan Djokic November 5, 2021

Hi @Charlotte Nicolaou , thanks for this, really useful! 

We're stuck at creating Employee object. Looking at this, it seems that you have done what we want to do, but we still don't know how :)

So, we have our employees as Jira users. But, as you've done, we want to create Employees as objects, so that we can link Laptops and other assets. Is there a way that we can connect them to Jira users and keep them synced? How can we have a full list of employees always in that Object group?

Thanks!

Gerard Phillips November 13, 2021

Hi @Dusan Djokic,

In this article, Charlotte talks about federating your data by linking it to another source such as Active Directory. There are LDAP integrations you can set up to pull data from AD, or from another system with employee data. You can even pull data from a CSV file, if needed. 

How to structure assets and configuration items in my Insight CMDB (atlassian.com)

I'm considering this option in my instance.  

Dusan Djokic November 15, 2021

Hi @Gerard Phillips ,

I've looked at that post, but I think it's only for Jira DC version and we need this functionality in Cloud. If you have found a way to integrate Jira Insight for Cloud User field in any other way but importing CSV as User object - pls let me know :) 

It's incredible to me that you can have perfectly good User field which is populated by Jira Directory of users, but you cannot use that to link Assets in any other way, but instead you should create separate "Employees" Object type to do all those things, and then keep them updated by importing CSV or manually create new Employees - pure redundancy for my team.

Thanks!

ian January 27, 2022

Not sure this is the best place for these questions so will also ask in the community forum.

Thanks Charlotte for this and your other articles re Insight. I've found them really useful during our trial of JSM Premium. Now looking at adding custom fields linking issues etc. to assets like computer of person reporting issue. Just realised that I need to specify the schema for each custom field and now a bit confused about best place to manage assets like computers - discovery or a separate assets schema?

This article talks about a separate schema for employee assets like laptops in addition to the Discovery schema. I'm suspecting that these were just examples showing capabilities rather than specific advice about how to manage assets. Now thinking the best solution for us when using Discovery is to manage discoverable assets like computers in the one schema - the Discovery schema. And add extra attributes we need to objects in the Discovery schema. Also manually add any non-discoverable assets of the same type to the Discovery schema. Is this what most organisations do when using Discovery?

Emma Oliver April 26, 2022

Hi @Charlotte Nicolaou has there been any progress on the template in the past year or on any of the integrations so you can pull data from SCCM, JAMF etc?

Thanks

Steven Lees-Smith May 18, 2022

@Charlotte Nicolaou   Where is this configured?

The ‘Employees’ object type is linked to the Jira user for the employee. By having that linked to the employee object type, when a hardware related request comes in from a Jira user, automations can be used to find that user’s Insight entry based on the $Jira user attribute, and then see all of the different objects that they own and pull them into the Jira issue if relevant.

We are importing the email address of our customers into Insight as part of the asset management regular import and it would be good to link to the Jira customers based on the matching email - I don't get how to make the link so it can be referred to.

Like Jan Odvárka likes this

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events