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

By Derek Fields

In my last Blog, I described how to model our Facilities and Equipment for our Facilities Management Service Desk. This week, we are going to create the Jira custom fields that will allow us to put those objects into our Jira tickets and use them to assist our users in providing us with accurate information about their requests. If you are just “tuning in,” you might want to go back and read Parts 1 and 2 before reading this post.

As a reminder, this is what our Facilities structure looks like in Insight:

We are going to create 5 custom fields for the top-level objects: Building, Floor, Wing, Location and Equipment. We don’t need to create Custom Fields for the sub-types of Equipment because when our end-user specifies the equipment that needs service, the end-user doesn’t care whether it is replaceable or serviceable. They just want the problem fixed. All they need to do is tell us which piece of equipment. The rest is left up to our Facilities Management team.

To create the Insight custom fields, we navigate to the Custom Fields section and select “Add custom field.” We then select Advanced and “Insight Object/s”. (Note that there are some deprecated fields as of this date – you should never use them!) Here is the Custom Field Type selector

Our first field is Building. Once you have created the field and added it to your Service Desk screen(s), you need to configure it to use the Insight object. Find the field in the Custom Field list and select Configure. From the Configuration screen, select Insight Configuration. This will bring up the Insight Configuration screen.

For the Object Schema, select the name of the schema that you have created. Mine is called Facilities.

For the Filter Scope, use “ObjectType = Building”. This tells the field to allow only Building objects to be selected into this field. We will leave the other fields blank.

On “Filter objects with attributes”, I have specified “Name” and “Address”. This will show both the building name and its address in the drop down list, allowing my user to pick the correct building more easily. Here is a picture of how it looks on the Portal to the user when they select the Building field

As you can see, both the building name and its address are shown. The specific field values are also searchable by typing any part of the Building Name or Address. If I have 25 different buildings that I maintain, it might be easier for the user to start types “Corporate Drive” and see just the buildings located on that particular street.

On the “Object attributes on Issue view”, I have added “Address”. This will add the Address of the Building onto the Issue view, which provides additional information for our Agent. Since the Name of our Building is also considered its “Label”, it shows by default. We can add any additional information to the issue view that is appropriate to show to the Agent. In this case, we will leave it as Address. It shows like this on the Issue View:

Building 1 Label

Now that we have created the Building field, we are going to create the other 3 Facilities fields. Instead of using the regular “Insight Object/s” field type, we are going to use the “Insight Referenced Object (single)” custom field type:

We do this because the rest of our Facilities location fields should be constrained only to the values that are appropriate to their parent field. Here is how the Floor field is configured:

In the Parent Custom Field, I have put Building. What this does is to constrain the available choices on the Floor drop down to only those floors that have the selected Building as their parent. If no Building is selected, no Floors will be shown to the user. They must select a Building first. As a reminder, here is how we configured the Floor Insight Object:

By specifying Building as an attribute on the Floor, we created an Inbound Reference on Building for all of the Floors that contain that Building their Building field. We can see this by looking at the Building object view for Building 1. Focusing only on the Inbound References section of the Object view, we can see that there are 3 Floors that reference this Building:

Looking back at the Custom Field definition, you can then see why we specified that we want Inbound References for Building to determine what will be shown in the drop-down list for Floor.

By configuring it this way, when you show the Building and Floor fields on the Portal, they look like this:

Having selected Building 1, I now get a drop down list of only the Floors that are in Building 1.

Now that we have created the Custom Fields for Building and Location, we can create the other fields for Wing and Location. Those are done the same way as Floor, except that the parent for Wing is Floor and the parent for Location is Wing.

For the Equipment field, we want the user to only have access to equipment that is tied to that specific location. This will reduce data error and lead to a faster response time, since our technician will know exactly what piece of equipment they need to address.

We could use the same technique as Floor, Wing and Location – we could specify the Location as the Parent for Equipment. However, in order to show you how you can incorporate placeholders into your Custom Fields, we are going to use a regular Insight Object/s custom field type. Here is the configuration:

The first thing that you will see is that the Filter Scope is a little different from the Location field. Here we need to use an Insight Query Language (IQL) function that returns a list of all of the sub-types of Equipment. Since we don’t know what type of equipment the user will specify, we need any piece of equipment that is located at the the specified Location.

In the Filter Issue Scope field, we have used a placeholder ${Location}. This specifies that we want the Location attribute to match the value in the Location Issue field that the user has specified. The use of placeholders allows us to dynamically select Insight objects based on other data that the user has entered on the Issue.

This completes the creation of the Custom Fields that we need to drive our Service Desk. In the next Blog post, we will place these fields onto a Request Type and look at the Workflow for our Facilities Management Service Desk.

What questions do you have about this implementation? Do you find this helpful or confusing? I would love to see your comments. Thanks for spending this time with me.

2020-08-07T11:47:05+00:00August 7th, 2020|Atlassian Community|

About the Author:

Derek Fields is the Atlassian Practice Manager for RightStar. He leads a talented group of highly experienced Atlassian consultants focused primarily on Service Desk implementations. Derek has over 30 years of experience as a software developer, architect, project manager and Agile enthusiast.

Leave A Comment