# Stop returning a list of sys_id's

In ServiceNow, records are uniquely identified by their sys\_id. When there's a need to retrieve a list of records, the sys\_id is often used to fetch these records. However, is this the most efficient method for returning a list of records?

---

Let’s break it down into a simple example. You got a **business rule** running **on** the **Incident table**. The business rule should contain a **script** to **close** all **related incident tasks**. You also got a **script include** “**IncidentService**” containing all business logic for incidents. The **objective** is to **retrieve** all the **related incident task records and close them**.

<div data-node-type="callout">
<div data-node-type="callout-emoji">❗</div>
<div data-node-type="callout-text"><em>We could do a GlideRecord on the business rule, however this violates the service pattern as the business logic should remain consolidated within the service layer.</em></div>
</div>

# How NOT to do it

*The following example is executing a GlideRecord, followed by adding all the sys\_id to an array. At the end of the query, the array is returned.*

```javascript
getRelatedIncidentTasks: function(incident){

    var taskIds = [];
    var grIncidentTask GlideRecord('incident_task');
    grIncidentTask.addQuery('parent', incident.getUniqueValue());
    grIncidentTask.query();

    while(grIncidentTask.next()){
    taskIds.push(grIncidentTask.getUniqueValue());
    }
    return taskIds;
}
```

## **Pros & cons**

✅ Very performance friendly  
✅ Can be returned to the client side  
❌ No possibility to retrieve additional attributes or related parent references

# How to do it right

Instead of fetching just the sys\_id, and returning it, return a queried variant of the GlideRecord Object. This is a very simple and reliable way to return the results whilst still being able to decide how the result should be utilized.

```javascript
getRelatedIncidentTasks: function(incident){
    var taskIds = [];
    var grIncidentTask GlideRecord('incident_task');
    grIncidentTask.addQuery('parent', incident.getUniqueValue());
    grIncidentTask.query();
    return grIncidentTask;
}
```

This is what the business rule could look like.

*We are fetching the queried GlideRecord object, then we query over the results.*

```javascript
var incidentService = new IncidentService();

var grIncidentTask = incidentService.getRelatedIncidentTasks(current);
while(grIncidentTask.next()){
    grIncidentTask.setValue('state','7'); //close
    grIncidentTask.update();
}
```

## **Pros & cons**

✅ Still performance friendly  
✅ Reusable for fetching values (or parent records) without the need for additional GlideRecord  
❌ GlideRecord instances cannot be retrieved on the Client side.

<div data-node-type="callout">
<div data-node-type="callout-emoji">💡</div>
<div data-node-type="callout-text"><em>Being unable to retrieve GlideRecord from the script include is not necessarily a bad thing. The client can delegate to a script include (ajax service layer) responsible for translating the GlideRecord into a client understandable format (JSON).</em></div>
</div>

---

# Conclusion

In conclusion, while using sys\_id to retrieve records in ServiceNow is common, it may not be the most efficient method. Returning a queried variant of the GlideRecord Object enhances performance and reusability, allowing for more flexible data handling. Although it has limitations, such as not retrieving GlideRecord instances on the client side, this approach aligns with the service pattern by consolidating business logic within the service layer, leading to more robust and maintainable code.

**In the next chapter, we will cover about delegating responsibilities to the service layer.**