Associate Service Requests to configuration items

[robsaunders]

Hi All,

I am looking for advise on how to implement some controls for audit purposes via our CMDB linked with new server build processes.

We plan to incorporate a New Server Request process into the Service Request Module in readiness for maturing this as an automation early next year.   Since the SRM portal is outside of the Core Platform I would like to understand how we create audit trails to configuration items that are created via this request portal.   I am working with an Service Integrator and I'm considering either one of two designs to support this however I have a key requirement to organise it so that CIs are either associated to SRM (if possible) or via RRCs.   Some advice on Best Practice is required for the 2 options below;

A) Build a new SRM form and have this approved via the authorised means.   Once built have the CI details associated against the SRM request.

B) Build the same SRM form and have the change automated so that the approval and build takes place.   Once built have the CI details associated against the change request.

Can you help.

Rob

[awessel]

I think both of the options you mention are viable and it'll largely depend on your environment and Change process/requirements. Technically speaking, both options are fairly simple and can be built using mostly OOB functionality. There's also nothing that would prevent you from going with both options.

Personally, I like the approach of associating the CIs to the RITM that would be created by the SRM form. This could be done fairly simply in the request's workflow. I'd suggest having the workflow create records in the CIs Affected [task_ci] table. This is an OOB table used to associate CIs to Tasks. It's also the table that Change uses OOB to associate multiple CIs to a single Change. One other related piece of functionality that could be leveraged if only a single server is being created is to populate the RITM's Configuration Item field in the workflow. This will in turn automatically create a record in the CIs Affected table.

The above suggestion assumes you're using some form of automation or have a way to determine the CIs that were created by the request. If that's being done manually you could just as easily add the Affected CIs related list and/or the Configuration Item field to the RITM form.

[robsaunders]

Hi Adam,

Thanks for the very helpful feedback to this.

Very interested in the concept of having both and the automated basis you refer to via the creation of the Ci.   We use an automation tool that would be used to build and naming standard the server.   This will complete the process and could return the CI data back for processing.   Having that possibly open a change is of interest since we have to organise operational acceptance within a different member firm (the firm that requested the server from the Operational Centre).   What would be entailed for this?

I also have heard that charges are applied for each automation so, in any of these viable options, would these relate to transactions that are charged on a per use basis.   Interested to know on this front.

Thanks and kind regards,

Rob

[awessel]

What this would entail would largely depend on the method of automation. Ideally, the workflow itself would handle the server creation and get the server data back from that automation. If you went that route, you could then take that returned data to create both the CI in ServiceNow and the Change Request in the workflow. That would also allow you to associate the CI you create to the RITM and/or Change Request. Most likely this would all be done via scripting in the workflow although there is a "Create Task" activity that could be used to create the Change Request.

There really are a lot of options and the exact solution that makes the most sense will largely depend on the particulars of your setup and requirements.

As far as the licensing costs go, that's something you'd need to discuss with your ServiceNow rep.

[mark243]

Hi Adam.  The output from this query contains a <ci_item> value, but it is blank.  Am I missing something?

https://company.service-now.com/api/now/table/task_ci?sysparm_limit=2

I'm trying to build a query in which I can query change tickets based on affected CIs I feed in.