Can only service schema be linked to OpsGenie?

Question

Hi,

Is it possible to link and use OpsGenie with a custom services schema we create in Insight rather than the default read-only services schema it uses?

As we cannot add attributes to the service schema, we are looking to build a custom service schema where we can add the attributes we want and use them.

Thanks,

Aman

Alex van Vucht (GLiNTECH) · Accepted Answer

Kind of. A few times now, I have created a "Business Service" object type and a "When Object Created: Service" automation rule to copy these Services to Business Service objects. It's not possible though to copy across change approvers, or any changes to the service like change of name or tier, so I scrapped linking these Business Service objects.

I've since moved away from creating Business Service object types altogether. Instead of Affected Services field on forms, I offer a Service Object Insight field and then use the new Placeholders feature to direct users to choose from CIs. Here's some settings for a cloud site I'm working on at the moment:

Object Type: Product

* Schema: Assets
* Key Attribute: Service (Object Reference type to Service object type)
* Abstract: True
* Children inherit attributes: True

I can then create service-specific object types which then link to the read-only Service schema objects, eg. "SharePoint Site", "Shared Mailbox", "Distribution List" object types.

Field: Affected Services

* Custom field ID: 10201

Field: Service Object

* Type: Insight object
* Schema: Services
* Scope IQL: objectType = Service
* Multiple: yes
* Custom field ID: 10378

Field: Product Object

* Type: Insight object
* Schema: Assets
* Scope IQL: objectType IN objectTypeAndChildren("Product")
* Issue Scope IQL: Service IN (${customfield_10378${0}})
* Multiple: yes

I then have an automation for setting Affected Services:

* Can be triggered by other rules: True
* When: Value changed for: Service Object
* If/else block* If Service Object is Empty
* Edit Issue Fields: Set Affected Services to Empty

* Else:* Edit Issue Fields: Advanced

{"fields":{"customfield_10201":[{"id":"{{issue.Service Object.Service ID}}"}]}}

And when you add the Service Object and Product Object fields to a form (make sure the form is visible, Insight Object fields don't work on hidden request forms!), when a user chooses a Service Object, the Product Object field then shows all the relevant objects for the service.

This way, you still are linking your custom schema to OpsGenie, but even better, you're allowing the configuration of your services to be linked to OpsGenie.

Alex van Vucht (GLiNTECH) · Accepted Answer

Hi @Aman yes I had a lot of trouble with that too. That's why I gave up putting the Affected Services field on screens, and instead putting the Service Object field. I recommend dropping the Affected Services field altogether from screens. The above automation will ensure the ITSM Change Management and Incident Management features will still work.

A further limitation I soon found is that the above automation doesn't support multiple values. Use this instead to support multiple Service Objects:

{"fields":{"Affected Services":[
   {{#issue.Service Object.Service ID}}{{values.displayValue.asJsonObject("id")}}{{^last}},{{/}}{{/}}
]}}

Understanding why you can't just use {{issue.Service Object.Service ID.asJsonObjectArray("id")}} and have to write the smart value this way delves into how Insight Objects are structured in automation. Understanding that will help you with further automating your Insight Cloud database.

Regarding the following section:

*  I'll keep describing an Insight Object custom field for the Services object schema as "Service Object" here, and a "Product Object" in a separate schema, with a Service object reference attribute, as described in the other answer.
* The rules are working with Issue smart values, not Object smart values. (The When Object Created/Updated/Deleted... rule makes your rule work with an {{object}} smart value and that's similar to here, but the below structure pertains to issue custom fields)
* The rules below do not attempt to update another Insight object directly with information from an Insight object. That's not yet supported. You can use the Lookup Objects action to find more Insight objects, then update issue custom fields with those objects, then update the attributes objects in that issue custom field. That's demonstrated at the bottom.

You can't use JSON, text, or other smart value functions on Insight object attribute smart values because Insight object attribute smart values are quasi-objects that don't work like other smart values. You can preview this when you retrieve the attributes with appending "?expand=customfield_10378.cmdb.attributes" to the "rest/api/3/issue/ITSM-1" endpoint (referring here to the custom field ID in the example above, and example issue ITSM-1 in an ITSM service desk project with this field).

Automation does some shortcuts so you usually don't have to worry about the Insight object structure if you're doing simple updates on issues, but you seem the enterprising sort so you need to know this. Each level of an Insight object field is an array, ie. an Insight object custom field is an array of Insight objects containing an array of attribute objects containing an array of value objects. Here's the smart value structure for a Insight object custom field:

issue:

* customfield_10378 / Service Object:* id: object's value ID, unique for each object within an Insight workspace (ie. across all schemas)
* label
* objectKey
* objectType: Name of object type
* objectType.id: Object type's ID
* objectType.description
* objectType.objectSchemaId
* objectType.icon & objectType.icon.name: The name of the icon used for that object type
* objectType.icon.id
* objectType.icon.url16
* objectType.icon.url48
* attributes:* id: the object's attribute value ID, unique for each object.
* type.name: the object attribute's name
* type.id: the object attribute's ID, this is what you see in the left column when editing attributes for an attribute type
* type.type: The category of this attribute's type, which tells you which of the following has more information on this attribute. Values have been observed to include "DEFAULT","STATUS","USER","REFERENCED_OBJECT". I have only been able to get further details on basic (ie. default) attribute types.
* type.defaultType.id: The ID for this basic type of attribute
* type.defaultType.name: The basic attribute type, eg. Text, DateTime
* values:* displayValue
* searchValue
* value (for basic attributes)

Some notes:

* You cannot access the Insight Workspace ID.
* The list of attributes on an object will only contain attributes that have values on that object. Don't count on the order of attributes being the same.
* You'll note that there are no Referenced Object attributes. A Insight Object smart value doesn't contain referenced objects; when you call a referenced object, Automation loads that object for reference. So you could do {{issue.Product Object.Service.Service ID}}.
* When manipulating attribute smart values, you are actually working with the attribute object above. If you want to do any functions to this object, you have to access the values.displayValue.

Hence the dance to update Affected Services with multiple Service Objects. eg. for updating from Product Objects, the JSON would be:

{"fields":{"Affected Services":[
{{#issue.Product Object.Service.Service ID}}{{values.displayValue.asJsonObject("id")}}{{^last}},{{/}}{{/}}
]}}

You can show all values for a Insight object custom field with this test rule:

* When: Scheduled:* Advanced cron: 0 0 0 1 1 ? 1970
* Searches with: Key = ITSM-1

* Then: Add comment:

{{#issue.Product Object}}{{label}} ({{objectType.name}}): 
{{#attributes}}
- {{type.name}} ({{if(not(exists(type.defaultType.name)),type.type)}}{{type.defaultType.name}}): {{values.displayValue.join(", ")}}
{{/}}{{/}}

When you click "Run rule", it will report on all the attributes and their attribute type on the Product Object custom field as a comment.

So let's say you want to create an incident when a license is going to expire for a product. Let's add to the object schema above:

Insight Object type: Product

* License expiry: Date type
* Status: Status type

Automation rule: Daily expiring licenses report

* When: Scheduled: Daily
* Lookup Insight objects* IQL: objectType IN objectTypeAndChildren(Product) AND "License expiry" < now(30d) and Status = Active

* If: Advanced compare: {{lookupObjects.size}} > 0
* Create service request: Report a System Problem* Summary: Expiring service licenses for {{now.jiraDate}}
* Urgency: Low
* Impact: Moderate
* Product Object: Key IN ({{lookupObjects.objectKey.join(",")}})
* Additional fields: (See below)

* Branch rule: For most recently created issue* Edit Insight field attributes* Status: Support requested

The JSON for the Additional fields:

{
    "fields": {
        "Affected Services": [
            {{#lookupObjects.Service.Service ID}}{{values.displayValue.asJsonObject("id")}}{{^last}},{{/}}{{/}}
        ]
    }
}

This rule will create an incident, link to the objects with expiring licenses, link to the Affected Services, and then update those objects with a new Status.

Note that this is undocumented so Atlassian reserves the right to change the Insight smart value structures at any time without warning. Use this in production systems at your peril. You have been warned.