Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Using Insight as an Object-Oriented Database (Part 2)

In my last post, I introduced the idea of using Insight as a general-purpose Object-Oriented database to allow you to extend the Jira data model to capture information about objects and not just about issues.

In this post, we will look at how to model Facilities in Insight so that you can create a simple Facilities Management Service Desk using Jira Service Desk and Insight. Lets get started by stating some basic requirements that we want our service desk to meet:

  • Our facilities consist of Buildings, which have Floors, which have Wings (West, North, South, East), which have Locations. Note that I have capitalized Buildings, Floors, Wings and Locations because these are going to be object types that we want to capture.

  • We also have Equipment, which is a general term that we will use for any device or object that our facilities staff might have to repair, replace, or service.

  • We will distinguish between two types of Equipment: Replaceable and Serviceable. A Replaceable item is one that is not generally fixed, but is replaced. For instance, the light bulb in a light fixture is replaceable while the light fixture itself may be serviceable.

  • Of greater interest for serviceable items are those that need maintenance. These are a subset of Serviceable that we will call Maintainable. A Maintainable item is one that we will regularly provide with preventative maintenance so that we reduce the number of service calls for that piece of Equipment.

The following requirements will be discussed in a following article, which is how we are going to set up our service desk Issue Types, Request Types and Workflow

  • We will have two Issue Types. A Service Call, which is a request to repair or replace a piece of Equipment and a Maintenance request, which is a routine call to perform maintenance.

  • We will have one Request Type that is a Service Call.

  • Our workflow will be quite simple. The ticket will be Open, Scheduled, In Progress and Done. This is certainly too simple for a real Facilities Management service desk, but for our purposes, it will be sufficient, since the point of this exercise is not to demonstrate workflows, but to demonstrate the use of Insight to model our objects.


Now that we have our basic requirements, lets look at how these lead to our design. The following diagram demonstrates a very simple hierarchical structure. Based on this structure, we should be able to allow our user to specify a specific location and send our technician to the right place without any guessing. We have added a Notes field to each object so that we can indicate information that might be pertinent to that object, such as “The door is on the West side” or “Stairwell” or “Make sure you bring earplugs - it is very loud”

Building Objects.png


(Aside: we could have model Wings above Floors. This is a design choice that should reflect how you and your facilities staff think about the real-world Floors and Wings represented by these objects)

The next diagram illustrates how we set up the Equipment model. This is a little more complicated because we illustrating inheritance, not hierarchy.

Equipment Model.png


Now that we know what our model looks like, lets implement it in Insight.

We start by creating a new Insight Object Schema that we will call Facilities with a key of FAC. Now that we have our empty schema, we can start by creating our objects, as designed above.


This illustrates the Building object type. I will create the rest of the object types the same way before I populate the attributes in them. Here you can see the Building/Floor/Wing/Location objects.


Note that I name them in the singular. These are not tables where we are keeping rows of buildings. These are types of objects and each object will be of type Building or Floor. So, we want to refer to the Object Type in the singular.


Remember that the Equipment hierarchy uses Inheritance in its data model. Lets take a short digression to discuss the concept of inheritance, which may be unfamiliar to you unless you happen to be an object-oriented software developer. Inheritance is the idea that one object type is a sub-type of a higher level type. You can see this in the Equipment Model that we presented above. We have two sub-types of Equipment: Equipment that is Serviceable and Equipment that is Replaceable. Each of these has its own fields but they also “inherit” the fields from their parent, which is the Equipment type. Further, we have another sub-type of a Serviceable object that is Maintainable, which has additional information regarding the maintenance schedule and guidelines. Generally, when an Object Type is a child or sub-type, it inherits all of the attributes of the parent type and then adds a few attributes of its own. There are exceptions to this rule, which are outside the scope of this article.

In order to make Equipment attributes inheritable, we need to check the box in the Object Type Configuration screen that will cause the children to inherit the parent’s attributes.


Note that we also set the object type as abstract. This simply tells Insight that we aren’t going to be creating objects that are only Equipment. All of our objects have to be either Replaceable or Serviceable. By setting the abstract checkbox, we are simply enforcing this policy.

Because of the way Insight is implemented, you must set the Inheritance checkboxes above BEFORE you create any of the child types. If you forget or later decide to make an Object Type a child of another type, you won’t automatically inherit the attributes and you may have to reimplement your schema.


The reason for talking about inheritance will become clear was we look at how we create the Equipment types. In in the picture below, you can see that for Replaceable, we have specified that it has a Parent, which is the Equipment type:


When we create each of the Equipment child types, we indicate the parent type for this object. This means that Serviceable and Replaceable both use Equipment as their parent. Maintainable uses Serviceable as its parent. This results in the following complete Object Schema.


What you can see in this illustration is the inheritance from Equipment to Serviceable to Maintainable.

You may be asking at this point, why didn’t we do the same thing for Building and Floor and Wing and Location. This is a common mistake if you are new to object-oriented thinking. When you are thinking about inheritance, ask yourself, “Is this Object a type of another Object or does it belong to or part of another Object?” In this case, we say that a Serviceable object is a type of Equipment but a Floor belongs to a Building. Only the is a type of statement means inheriting from the parent.

Now lets look at how we manage the “belongs to” or “is part of” relationship between objects.


Each characteristic or data point on an Object is called an Attribute. An attribute corresponds to a column in a database table.

The following shows the attributes that we have defined for the Floor object type


The first four attributes - Key, Name, Created and Updated - are all standard attributes that Insight adds to every object type. In addition, we added the Notes attribute. More important, we added the Building attribute. Notice that under Type, we have selected Object instead of Default. This allows us to say that this attribute is another Insight object. In this case, Building. Under Additional Value, we have selected the “Is In” relationship type. This is a custom relationship type that I added in my environment. You can select “Dependency,” which is a standard type. This is just for documentation purposes and has no practical effect in our implementation.

I used the “Is In” relationship type for Floor, Wing and Location. To make this clear, here is the Wing object type:


In this case, we defined the attribute Floor to point to the Floor that the Wing is on.

The Equipment model is a little different because we are going to use inheritance. Here is the definition of the Equipment object type:


We have an Attribute called “Location” that references the Location where the equipment is found. We don’t need to specify this again for the other Equipment object types because they are going to inherit all of the fields that you see here. For instance, here is the Serviceable object type:


You can see by the hierarchy icon on the left of Location that this attribute was inherited from its parent. We added the Service Guidelines and Manufacturers Link attributes to the Serviceable object type.

The Maintainable object type further inherits from the Serviceable type


Maintainable has inherited the attributes from Serviceable and added two additional attributes: Maintenance Procedures and Maintenance Interval

When we are done with all of the object types, we can see a graphical view of our object model that looks like this:


Moving Forward

This was a long discussion about how to model our equipment in Insight. Next week, we will discuss how we tie this Insight object model to Jira Service Desk to allow the equipment and locations to be used to help our users get us the information that we need to support them.



M Amine
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Sep 28, 2020

Insight AM is really powerful. Thank you for this article.

surely these articles are very interesting and confirm that the plugin is very powerful. I am working right now with the cloud version of this plugin and it seems to me that it is still incomplete, in the sense that you can't do everything you describe. Am I wrong ? Or are you confirming that it is ? Starting for example even from the support request: if you write to Atlassian they answer that you have to forward the request to the old site of the old plugin owner. There is a lot of space for improvement I think, don't you agree ?

Bless you Derek for writing this article!

It seems that all available support articles only brush the surface of Insight but yours actually has practical advice on implementation.

Very much appreciated, thank you sir!


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events