Configuration Item field on ticket forms

[gagribben]

Hello, I want to understand how others are using the Configuration Item field that is present on most, if not all, the ticket forms (change, Request Item, Task, incident, etc). 

From my understanding, the Configuration Item field is present on all the ticket forms as a way to track the tickets associated with a particular CI.  In such a case, you can add a related list for each of the types of tickets to the cmdb_ci record form. 

If that is the intended use. What methods are you using to populate this field on a given form? In our environment, we have variables on the catalog item that the requester would enter as the affected, impacted device, currently a string. I am suggesting converting to a reference lookup against the respective cmdb_ci table. Then, adding a business rule that would map the value from the catalog item variable to the Configuration Item field on the ticket form. I am struggling as that could potentially get messy very quick due to the sheer number of different catalog items that we have in our environment and ensuring that each variable has an associated business rule to update the Configuration Item field on the form. 

How are others using this field?

[lpruit2]

Greetings @gagribben. You are correct that a lot of tables have the, or a, Configuration Item Reference field. This field lives on the Task [task] table and is a reference to the Configuration Item [cmdb_ci] table. Because it lives on the Task table [task], any table that extends Task will have access to the same field. Since the Incident table [incident] extends the Task table, the Incident table is inheriting the Configuration Item field. 

Are your Catalog Items / Record Producers pointing to tables that extend the Task table or tables that already have a Configuration Item field? If so, you could simply create a new Variable of type Reference and map that new Variable to the existing Configuration Item field on the target table. There would be no need to create a Business Rule. 

In my opinion, creating a new Reference field to capture Configuration Item information is much better than a String field. Having a String field to capture information tends to have limited reporting accuracy when you try to aggregate or analyze records and trends. 

[gagribben]

Thank you very much for your response. 

Yes the Record Producers are pointing to tables that extend the task table. We are only using change_requst, change_request_task, Incident, sc_request, sc_req_item, sc_task. So it should be simple enough to create the reference and map as suggested. 

That's the problem, there are currently string fields that users are able to enter whatever information they want without validation or reference, which confuses fulfillers, especially if the name doesn't match exactly or there is a typo. 

[Renat Akhmedov]

Hi @gagribben,

Per-item Business Rules will become unmaintainable very quickly. Instead, I'll suggest:

Create a variable set that contains your CI variable (example):

Variable name: ci

Type: Reference

Reference: cmdb_ci (or a child table like cmdb_ci_computer).

Reuse this variable set on every item where you need a CI.

Create a single Business Rule on sc_req_item (or on task) such as:

When: before insert (and maybe before update)

Condition: current.cmdb_ci.nil()

Script:

(function executeRule(current, previous /*null when async*/) {
    var ritm = current;
    // Adjust 'ci' to your variable name
    var ciVar = ritm.variables.ci;
    if (!ritm.cmdb_ci && ciVar) {
        ritm.cmdb_ci = ciVar;
    }
})(current, previous);

It will give you that any item that uses that variable set will automatically populate CI without extra rules.

Hope it was helpful, 

Best regards,
Renat Akhmedov