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.
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.
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
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.
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.
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.
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 .
‘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.
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:
-
‘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.
-
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.
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.
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.
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
Virtual guest
Host
Metdata object types
We have also added a few extra object types to the Insight Discovery object schema under the heading ‘Metadata’.
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.
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.
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!
Was this helpful?
Thanks!
Charlotte Nicolaou
13 comments