Overview

In ServiceDesk Plus (SDP), linked requests help track related tickets efficiently. A request can either be a Parent (having linked requests) or a Child (linked under another request). Analytics Plus stores this relationship using two key fields:

• Linked Request (Boolean Field) → Identifies if a request is a Parent.
• Linked Request ID → Stores the Parent Request ID for Child requests.

This document explains how linked requests work, why child requests store the Parent ID, and how to report on them effectively.

How Linked Requests Work in SDP

When requests are linked:

1️⃣ The oldest request becomes the Parent.
2️⃣ Any newer requests linked to it become Child Requests.
3️⃣ A Child Request can also act as a Parent if more requests are linked under it.

Example: Parent-Child Structure

The Parent Request (237965) holds the primary responsibility, while its Child Requests (238274, 239100) are tracked under it.

How Linked Requests Are Represented in Analytics Plus

Analytics Plus tracks this structure using two fields:

1. Linked Request (Boolean Field)

• ✅ TRUE → Request is a Parent (it has linked Child Requests).
• ❌ FALSE → Request is either a Child or an independent request.

2. Linked Request ID (Parent Request ID)

• 📌 For Child Requests → Stores the Parent Request ID to show its association.
• 🚫 For Parent Requests → This column remains empty because a Parent does not link upwards.

Example: How It Appears in Analytics Plus

Why Does the Child Store the Parent Request ID?

When a request is linked as a Child, it needs a way to identify its Parent. Instead of storing multiple child requests under a single Parent row (which is inefficient for querying), each Child simply stores the Parent Request ID in its own row.

This setup allows for easy filtering and reporting without complex joins.

Multi-Level Linked Requests (Chained Requests)

A Child Request can also be a Parent if additional requests are linked under it. This creates a hierarchical chain of linked requests.

Example: Multi-Level Parent-Child Requests (Jus for Reference)

📌 237965 (Top-Level Parent): No Parent Request ID.
📌 238274 (Child & Parent): A Child to 237965 and a Parent to 239500.
📌 239500 (Child of 238274): Linked under 238274.

Why This Matters

✅ Better Incident Management

• Grouping related requests ensures faster resolution.

✅ Efficient Escalation Handling

• IT teams can prioritize Parent Requests that have unresolved Child Requests.

✅ Simplified Reporting & Tracking

• Easy identification of relationships without complex queries.

Conclusion

• Parent Requests → ✅ Linked Request = True, Linked Request ID = Empty
• Child Requests → ❌ Linked Request = False, Linked Request ID = Parent Request ID
• Multi-Level Requests → A Child can also be a Parent if further requests are linked.

This structure ensures clarity in linked requests, simplifies reporting, and improves IT service management.

Note :  the Linked RequestID is displaying the WorkorderID (shown in the URL of the ticket) instead of the RequestID.

If you expect to see the Parent Request ID when Linked Request = True, and want the Linked Request ID to be displayed in the same row as the Parent Request, we may need to build a query to achieve this.

Here’s a query :

SELECT  

    r."RequestID",  

    r."Request Display ID",  

    r."Created Time",  

    r."Linked Request",  

    r."Linked RequestID",  

    lr."Request Display ID" AS LinkedRequestDisplayID  

FROM Request r  

LEFT JOIN Request lr ON r."Linked RequestID" = lr."RequestID";

Output: