How to Link Service Requests (RITMs) to Incidents and Make the Incident Reference Mandatory

[dasarisuren]

Hi Team,

I have a requirement to link Service Requests (RITMs) to Incidents in ServiceNow.

Requirement:

1) A Service Request (RITM) should be associated with an Incident.

2) The relationship should be visible through the Requested Items related list on the Incident form.

3) The Incident reference should be mandatory while creating or processing the Service Request.

4) Users should not be able to submit/process the request without selecting an Incident.

[Ankur Bawiskar · Accepted solution]

@dasarisuren 

what's your business requirement?

You can create REQ from INC and the INC number gets populated in Parent field

Using that you can establish relationship

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar · Accepted solution]

@dasarisuren 

what's your business requirement?

You can create REQ from INC and the INC number gets populated in Parent field

Using that you can establish relationship

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Shahjay · Accepted solution]

Hi @dasarisuren ,

Worth confirming the underlying requirement first — making an Incident mandatory on all service requests is unusual, since most requests don't originate from one. The design below assumes the common case ("RITMs raised from an Incident should be visible on that Incident") and stays scoped to specific catalog items.

Use the existing Task hierarchy — you don't need a custom m2m table.

sc_request, sc_req_item and incident all extend task, so task.parent is already a reference to task. That's your link.

Here's the bit that catches most people out. When you create a request from an incident out of the box, the incident lands on the **REQ's** parent field, not the RITM's. So if you go to Configure > Related Lists on the Incident form you can add "Request → Parent" today and you'll see REQs straight away. But you asked for Requested Items, and that related list reads `sc_req_item.parent`, which nothing populates out of the box. That's the gap you have to close yourself.

So, step 1: put a variable on the catalog item — Reference type, pointing at Incident [incident] — and tick Mandatory. That covers your point 4 for anyone ordering through the portal or workspace.

Step 2: copy it onto the RITM with a Before Insert business rule on `sc_req_item`:

(function executeRule(current, previous /*null when async*/) {
if (current.variables.u_incident_ref) {
current.parent = current.variables.u_incident_ref.toString();
}
})(current, previous);

Swap `u_incident_ref` for your variable's real backend name. And set the condition to `Item is <your item>` (or `Item is one of ...` if several items need it) so it never runs against laptop requests, access requests and the rest.

Worth saying, since it comes up every time this is discussed: `current.variables` does work in a Before Insert rule on `sc_req_item`. That's the normal mapping pattern and it saves you an unnecessary `current.update()`. If you'd rather inherit from the REQ that the OOTB UI Action created, the rule is just `current.parent = current.request.parent;` instead.

Step 3 — Configure > Related Lists on Incident, add "Requested Item → Parent". Nothing custom needed, it's available because `sc_req_item.parent` references Task.

Step 4 -  for your point 3. Put Parent (or a dedicated `u_incident` field) on the RITM form, make it mandatory with a UI Policy, and back that with a Data Policy so list edits, imports and API writes can't slip past it. Then make it read-only after insert, either through the UI Policy or a write ACL. Mandatory only stops the field being empty when the record saves; it doesn't stop a fulfiller clearing it and re-saving with something else in there. If the link matters, lock it.

Condition all three on the catalog item. I'd underline that one. An unconditioned Data Policy on `sc_req_item` will stop every single RITM in the instance from saving without an incident, and you'll find out about it very quickly.

One last thing if point 4 needs to be genuinely watertight. A mandatory variable only protects the catalog UI — scripted ordering through `sn_sc.CartJS` or the Service Catalog REST API goes around it. If that's a real risk in your environment, add a scoped Before Insert abort:

if (!current.variables.u_incident_ref) {
gs.addErrorMessage(gs.getMessage('An Incident must be selected for this request.'));
current.setAbortAction(true);
}

Two gotchas to save you some time. If you're leaning on the OOTB Create Request flow to populate parent, it works off `sysparm_parent_sys_id` and `sysparm_parent_table`, and it quietly does nothing if "Use Cart Layout" is switched off in the item's cart settings. That's far and away the most common reason people post saying their parent field is empty. Second, because the related list sits on a reference field, anyone with write access to parent can drag RITMs in and out of it and silently re-parent them — and a RITM only ever has one parent, so one incident.

Which leads to the exception. If you really do need one RITM linked to several incidents, don't build a custom table for it. Activate the Task Relations plugin and use `task_rel_task` — it's already there for exactly this.