How do i get our computer assets to be prepopulated on a incident?

[Gary.Smith]

I am trying to get to a point where I have a field on an incident for assigned assets where the 'assigned asset user' matches the incident owner\creator.

I also need to assign users to our assets (where they may not be Jira users).

Where I am getting stuck is, I am using the Discovery Tool\Agent which populates a 'Last User' field with the username. I commented out the line in the pattern so now I get Domain\User on the asset.

I now need to match this user (Last User) to an Object of the User. That can't be the Jira user as we have more users than just the ones in Jira access groups. So I have imported our active directory accounts as an Insight object ('Active Directory Accounts').

Then I need to match that to users that are Jira users so that when they log a ticket it can be calculated.

I'm so lost with this process and just keep going down rabbit holes trying to script a solution.

How can I do this using Insight? This is the 3rd CMDB I have set up but is by far the hardest one yet due to its limitations.

[Alex van Vucht (GLiNTECH)]

Hey @Gary.Smith

For a start, I recommend loading your Insight Discovery data into a separate schema. It can get confusing when you have two object types with the same name. Make sure to select "Allow others to select objects from this schema" across all your schemas.

Let's break this down into two steps.

1. Setting the Active Directory user object on issues

I don't recommend working with Jira user attributes in cloud until you're more comfortable with Insight, because you have to work with Atlassian Account IDs. You can match your issue reporters with your Active Directory user objects based on email address.

Insight object type: AD user

• Username: Text attribute
• Email Address: Text attribute

Insight custom field: Reporter Object

• Schema: Your custom schema
• Scope IQL: objectType = "AD User"
• Multiple: No

Load your AD users into the AD user list.

Now the magic happens with an automation rule:

1. When: Field value changes for Reporter
2. Then: Edit issue:
   • Reporter Object: "Email Address" = "{{issue.reporter.emailAddress}}"

2. Setting the scanned Network Asset objects on issues

Insight custom field: Reporter Network Assets

• Schema: Discovery-only schema
• Scope IQL: objectType IN objectTypeAndChildren("Network Assets")
• Multiple: Yes

Then finish it with this automation rule:

1. When: Field value changes for Reporter Object
2. Then: Edit issue:
   • Reporter Network Assets: "Last User" = "{{issue.Reporter Object.Username}}" OR "Contact" = "{{issue.Reporter Object.Email Address}}"

Turn on "Check to allow other rule actions to trigger this rule" for these rules. It's good practice to do this for all your "Field value changes" rules and not other rules. This ensures your rules remain tidy and small.

Once these are working, it's a good idea to turn off error notifications, as this will frequently stop working if there is anyone who'll raise issues who hasn't been loaded yet into your AD User objects.

[Gary.Smith]

No wonder I've been having so much trouble. I didn't have access to Jira as an admin, only Insight, so I didn't even know there were automation rules!! I've now got access so I can see how things are set up on the JSM side. Quite a few things have clicked in place.

I'm still stuck with 2 things.

1. If I have a user that has a CI linked like this

Schema: Company Information
ObjectType: Contact Information
Attribute (text): Email Address
Attribute (Object): Assigned Devices (Linked to another ObjectType - Schema: Insight Discovery, ObjectType: Host)

And I want to match on email as you suggested above, but actually put in the Device that is linked from the 2nd Schema\ObjectType. How would I do that?

2. Is there a way to have an object be duplicated when it's created?

I don't want anyone to have access to the 'Discovery Data' schema as this is where the Tool\Agent is creating CI's in its own format. Instead, I want a second schema (Asset Store) where I will have ObjectTypes for Laptop\Desktop\Server\VM etc and set extra info like owners, purchase info etc.

Then when a CI is updated, update the fields that come from the discovery tool.

I noticed that you work for GLiNTECH in Sydney so I'm going to see if I can get some consulting time with you guys (if work approves it).

[Alex van Vucht (GLiNTECH)]

Hey, we're happy to help out. We've got a Managed Services team which can help with queries like this.

Attribute (Object): Assigned Devices (Linked to another ObjectType - Schema: Insight Discovery, ObjectType: Host)

And I want to match on email as you suggested above, but actually put in the Device that is linked from the 2nd Schema\ObjectType.

When you scan assets, it tells you who was the last user. That's why we generally don't set up "Assigned Devices" attributes on user profiles, but instead have "Assigned User" attributes on devices. When you import your assets, you match your user objects to your devices.

So:

Insight Object: Host

• Assigned User: Object attribute: Link to Contact Information objects

Insight custom field: Reporter assets

• Scope IQL: objectType IN objectTypeAndChildren(Host)

Automation rule:

1. When value for Reporter changes
2. Edit issue:
   1. Host object: "Assigned User"."Email Address" = {{issue.reporter.emailAddress}}

This works because you're looking up a property of the attribute. You can do it the other way around with the "inboundReferences" function but that's harder. That's along the lines of: objectType = Host AND object IN inboundReferences(objectType = "Contact Information" and "Email Address" = "{{issue.reporter.emailAddress}}")

2. Is there a way to have an object be duplicated when it's created?

When you import your devices, you can import the same data into multiple object types. This is true for the Insight Discovery scan data, and scan data from any other network scanning tools. You can't import into multiple object schema with the same import configuration, but you can set the permissions for your Discovery hierarchy to be hidden from regular users.