Skip to main content

RenderTypes for Relations

When to read this document

This document is intended for ServiceNow / Squid administrators wanting to understand how Squid works or creating custom configurations.

Accessing Squid as a data consumer does not require reading this document!

While References and Relations define what is to be rendered, RenderTypes define how that data is rendered.

RenderTypes have an impact on

  • the rendered JSON and with that what data is returned as well as how that data is structured.
  • the database load (some RenderTypes can cause exponentially more database queries).
  • your retrieved entities count. Some RenderTypes count toward your licensed entities limit.

Quick Decision Guide for Relations

First, decide where the relation should be rendered:

RequirementUse RenderTypes starting with...
Bulk export, optimized performanceRelation*
Single entity, self-contained JSONInline*

Then, decide what data to render:

Relation* RenderTypes

These render in the relations section.

Use CaseRenderType
Only need sys_id, no entity dataRelation SysId
Bulk export with full entity details (recommended)Relation Reference
M-to-N relation, field value is what you needRelation Literal
Human-readable display names (locale-dependent)Relation Display Value

Inline* RenderTypes

These render inline with the referencing entity and require Allow Inline Relations on the requested configuration.

Use CaseRenderType
Self-contained JSON, only need sys_idInline SysId
Self-contained JSON with full entity detailsInline Reference
Single entity request, fully nested JSONInline Content
M-to-N relation, field value inlineInline Literal
Human-readable display names inline (locale-dependent)Inline Display Value
Performance Recommendation

For bulk data exports, prefer Relation Reference over any Inline* RenderType.
Inline* RenderTypes cause additional SQL queries per entity and should be reserved for single-entity requests.

Relation Names are defined in the Relation Configuration and may be dynamic

Relation configurations define under what JSON property a relation should be rendered.

In the example below the caller is requesting the relation ci_to_user_group_minimal, but the relation data is rendered as a JSON property user_groups. This name may even be dynamically determined based on the data of the relation. See Relations for details.

Relation* vs Inline*

Relation* RenderTypes render the relation in the relations section of the returned JSON.

Inline* RenderTypes render the relation directly as property of the referencing entity.
Inline* RenderTypes are only permissible if the requested root configuration has Allow Inline Relations set.

{
...,
"data": [
{
...
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07",
"sys_mod_count": 12,
"sys_updated_on": "2024-07-17T10:54:43Z",
"user_groups": [ <= 'Inline*' RenderTypes render here
...
]
}
],
"relations": { <= 'Relation*' RenderTypes render here
"5f9b83bfc0a8010e005a2b3212c9dc07": {
"user_groups": [
...
]
}
},
...
}

Relation*

RenderTypes starting with Relation* will be rendered in the relation section of the returned JSON. This allows for consolidated database queries and is generally more performant.

Try it: https://demo.squid46.io/cmdb_ci_server_minimal?encodedQuery=base_name=dbaix901nyc&relations=ci_to_user_group_minimal

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_minimal": [ <= configuration the relations were requested for
"ci_to_user_group_minimal" <= requested relation
]
},
...
},
...,
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07", <= sys_id of requested server
"sys_mod_count": 12,
"sys_updated_on": "2024-07-17T10:54:43Z"
}
],
"relations": { <= relations section of returned JSON
"5f9b83bfc0a8010e005a2b3212c9dc07": { <= sys_id of requested server
"user_groups": [ <= relation name
{
"sys_id": "6577e5908f972410960c53ac37bdee66", <= sys_id of user group "Infrastructure"
"sys_class_name": "sys_user_group"
},
{
"sys_id": "b85d44954a3623120004689b2d5dd60a", <= sys_id of user group "CAB Approvers"
"sys_class_name": "sys_user_group"
}
]
}
},
"referenced": { <= referenced section of returned JSON
"6577e5908f972410960c53ac37bdee66": { <= sys_id of user group "Infrastructure"
"active": true,
"name": "Infrastructure",
"sys_created_by": "admin",
"sys_created_on": "2021-03-30T18:56:30Z",
"sys_id": "6577e5908f972410960c53ac37bdee66",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2021-03-30T18:56:30Z"
},
"b85d44954a3623120004689b2d5dd60a": { <= sys_id of user group "CAB Approvers"
"active": true,
"description": "CAB approvers",
"name": "CAB Approval",
"sys_created_by": "admin",
"sys_created_on": "2011-09-30T16:30:34Z",
"sys_id": "b85d44954a3623120004689b2d5dd60a",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2011-09-30T16:30:34Z",
"type": [
"itil"
]
}
}
}

Inline*

RenderTypes starting with Inline* will render the relation directly as property of the referencing entity. This forces us to retrieve the referenced entity the moment we are rendering the referencing entity. This will result in a potentially very high amount of database queries.

Try it: https://demo.squid46.io/cmdb_ci_server_inline_minimal?encodedQuery=base_name=dbaix901nyc&relations=ci_to_user_group_inline

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_inline_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_inline_minimal": [ <= configuration the relations were requested for
"ci_to_user_group_inline" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07",
"sys_mod_count": 12,
"sys_updated_on": "2024-07-17T10:54:43Z",
"user_groups": [ <= relation name
{ <= content inlined
"active": true,
"name": "Infrastructure",
"sys_created_by": "admin",
"sys_created_on": "2021-03-30T18:56:30Z",
"sys_id": "6577e5908f972410960c53ac37bdee66",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2021-03-30T18:56:30Z"
},
{
"active": true,
"description": "CAB approvers",
"name": "CAB Approval",
"sys_created_by": "admin",
"sys_created_on": "2011-09-30T16:30:34Z",
"sys_id": "b85d44954a3623120004689b2d5dd60a",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2011-09-30T16:30:34Z",
"type": [
"itil"
]
}
]
}
],
"relations": {}, <= relations are empty in this case!
"referenced": {}
}

Relation SysId

Relation SysId is the equivalent to SysId for references.

Relation SysId will resolve the relation and render sys_id and sys_class_name in the relations section of the returned JSON.

Try it: https://demo.squid46.io/cmdb_ci_server_minimal?encodedQuery=base_name=dbaix901nyc&relations=demo_ci_to_user_group_sys_id

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_sys_id" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07", <= sys_id of requested server
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z"
}
],
"relations": { <= relations section of returned JSON
"5f9b83bfc0a8010e005a2b3212c9dc07": { <= sys_id of requested server
"user_groups": [ <= relation name
{
"sys_id": "6577e5908f972410960c53ac37bdee66", <= sys_id of user group
"sys_class_name": "sys_user_group"
},
{
"sys_id": "b85d44954a3623120004689b2d5dd60a", <= sys_id of user group
"sys_class_name": "sys_user_group"
}
]
}
},
"referenced": {} <= references are empty!
}

Nothing other than sys_id and sys_class_name, if applicable, are rendered.

  • Relation SysId does not require or support a targetConfiguration.
  • Relation SysId causes no memory impact.
  • Relation SysId has minimal database impact. (One additional SQL query per relation type requested.)
  • Relation SysId relations do not count toward your licensed entities limit.

Relation Reference

Relation Reference renders a reference property exactly like Relation SysId, but will additionally add the referenced entity at the end of the returned JSON in the referenced section.

Relation Reference is the most efficient way to render relations with the referenced entity.

Try it: https://demo.squid46.io/cmdb_ci_server_minimal?encodedQuery=base_name=dbaix901nyc&relations=ci_to_user_group

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_minimal": [ <= configuration the relations were requested for
"ci_to_user_group" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07", <= sys_id of requested server
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z"
}
],
"relations": { <= relations section of returned JSON
"5f9b83bfc0a8010e005a2b3212c9dc07": { <= sys_id of requested server
"user_groups": [ <= relation name
{
"sys_id": "6577e5908f972410960c53ac37bdee66", <= sys_id of user group 1
"sys_class_name": "sys_user_group"
},
{
"sys_id": "b85d44954a3623120004689b2d5dd60a", <= sys_id of user group 2
"sys_class_name": "sys_user_group"
}
]
}
},
"referenced": {
"6577e5908f972410960c53ac37bdee66": { <= sys_id of user group 1
"active": true,
"name": "Infrastructure",
"sys_created_by": "admin",
"sys_created_on": "2021-03-30T18:56:30Z",
"sys_id": "6577e5908f972410960c53ac37bdee66",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2021-03-30T18:56:30Z"
},
"b85d44954a3623120004689b2d5dd60a": { <= sys_id of user group 2
"active": true,
"description": "CAB approvers",
"name": "CAB Approval",
"sys_created_by": "admin",
"sys_created_on": "2011-09-30T16:30:34Z",
"sys_id": "b85d44954a3623120004689b2d5dd60a",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2011-09-30T16:30:34Z",
"type": [
"itil"
]
}
}
}
  • Relation Reference requires a targetConfiguration.
  • Relation Reference causes negligible memory load.
  • Relation Reference has a minimal database impact.
    • One additional SQL query per relation type requested.
    • Potentially one additional SQL query per targetConfiguration. (References are resolved once per request, not per reference or relation.)
  • Every resolution of a Relation Reference counts toward your licensed entities limit unless that entity was previously cached.

Relation Inline Content

Will be correctly supported in Release 1.2.0. Currently renders incorrectly as Inline Content.

Relation Inline Content will render the relation in the relations section of the returned JSON and inline the content of the referenced entity. Hence, the name Relation Inline Content as opposed to just Inline Content which would also inline the relation itself.

Relation Literal

Only available for M-to-N relations

This RenderType only makes sense in an M-to-N Relation where the to column of the relation is something other than a sys_id. Otherwise just use Relation SysId.

Vanilla ServiceNow does not have any use cases for this RenderType, but what do we know what customers might build?

From a purely data architectural perspective, returning the to column of an M-to-N table is valid use case.

We might expand this RenderType to support Relations as that would be valid from a technical point of view, but only if and when customers present a real use case.

Give us a heads-up at Support if you think you need this.

Relation Literal will resolve the relation and render the literal value of the to field of the relation in the relations section of the returned JSON.

Try it: https://demo.squid46.io/cmdb_ci_server_minimal?encodedQuery=base_name=dbaix901nyc&relations=demo_ci_to_user_group_relation_literal

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_relation_literal" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07", <= sys_id of the requested server
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z"
}
],
"relations": { <= relations section of returned JSON
"5f9b83bfc0a8010e005a2b3212c9dc07": { <= sys_id of requested server,
"user_groups": [ <= relation name
"6577e5908f972410960c53ac37bdee66", <= the value in the 'to' column of the relation
"b85d44954a3623120004689b2d5dd60a" <= the value in the 'to' column of the relation
]
}
},
"referenced": {}
}
  • Relation Literal does not require nor support a targetConfiguration.
  • Relation Literal causes no memory load.
  • Relation Literal has a minimal database impact. (One additional SQL query per relation type requested.)
  • Relation Literal relations do not count toward your licensed entities limit.

Relation Display Value

Relation Display Value will resolve the relation and render the display value of the referenced entity in the relations section of the returned JSON.

As the returned values are potentially localized, this introduces a level of variance that is usually dangerous for technical integrations.

This is probably NOT what you want

While there may be legitimate use cases for Display Value (see examples mention in References Display Value), the rendered value can be dependent on the locale of the caller. This might lead to unexpected results.

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_relation_display_value" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07", <= sys_id of the requested server
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z"
}
],
"relations": { <= relations section of returned JSON
"5f9b83bfc0a8010e005a2b3212c9dc07": { <= sys_id of requested server,
"user_groups": [ <= relation name
"Infrastructure", <= the display value of the user group
"CAB approvers" <= the display value of the user group
]
}
},
"referenced": {}
}
  • Relation Display Value does not require nor support a targetConfiguration.
  • Relation Display Value can have a noticeable impact on performance.
  • Relation Display Value may cause substantial memory load, if a high variance of values is encountered as these values are cached.
  • Relation Display Value will cause an additional SQL query for every entity rendered. (This only applies to the first retrieval of a Display Value, as they are cached.)
  • Relation Display Value relations do not count toward your licensed entities limit.

Inline SysId

Inline SysId will resolve the relation and render sys_id and sys_class_name as a property referencing entity inline in the returned JSON.

Try it: https://demo.squid46.io/cmdb_ci_server_inline_minimal?encodedQuery=base_name=dbaix901nyc&relations=demo_ci_to_user_group_inline_sys_id

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_inline_minimal", <= requested configuration,
"requested_relations": { <= requested relations
"cmdb_ci_server_inline_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_inline_sys_id" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07",
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z",
"user_groups": [ <= relation name
{
"sys_id": "6577e5908f972410960c53ac37bdee66", <= sys_id of user group
"sys_class_name": "sys_user_group"
},
{
"sys_id": "b85d44954a3623120004689b2d5dd60a", <= sys_id of user group
"sys_class_name": "sys_user_group"
}
]
}
],
"relations": {}, <= relations remain empty
"referenced": {}
}
  • Inline SysId does not require nor support a targetConfiguration.
  • Inline SysId has no memory impact.
  • Inline SysId will cause an additional SQL query for every entity rendered.
  • Inline SysId is only permissible if the requested root configuration has Allow Inline Relations set.
  • Inline SysId relations do not count toward your licensed entities limit.

Inline Reference

Inline Reference renders the relation exactly like Inline SysId, but will additionally add the referenced entity at the end of the returned JSON in the referenced section.

Try it: https://demo.squid46.io/cmdb_ci_server_inline_minimal?encodedQuery=base_name=dbaix901nyc&relations=demo_ci_to_user_group_inline_reference

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_inline_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_inline_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_inline_reference" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07",
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z",
"user_groups": [ <= relation name
{
"sys_id": "6577e5908f972410960c53ac37bdee66", <= sys_id of user group 1
"sys_class_name": "sys_user_group"
},
{
"sys_id": "b85d44954a3623120004689b2d5dd60a", <= sys_id of user group 2
"sys_class_name": "sys_user_group"
}
]
}
],
"relations": {}, <= relations remain empty
"referenced": {
"6577e5908f972410960c53ac37bdee66": { <= sys_id of user group 1
"active": true,
"name": "Infrastructure",
"sys_created_by": "admin",
"sys_created_on": "2021-03-30T18:56:30Z",
"sys_id": "6577e5908f972410960c53ac37bdee66",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2021-03-30T18:56:30Z"
},
"b85d44954a3623120004689b2d5dd60a": { <= sys_id of user group 2
"active": true,
"description": "CAB approvers",
"name": "CAB Approval",
"sys_created_by": "admin",
"sys_created_on": "2011-09-30T16:30:34Z",
"sys_id": "b85d44954a3623120004689b2d5dd60a",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2011-09-30T16:30:34Z",
"type": [
"itil"
]
}
}
}
  • Inline Reference requires a targetConfiguration.
  • Inline Reference causes negligible memory load.
  • Inline Reference will cause additional SQL queries:
    • One additional SQL query per entity.
    • Potentially one additional SQL query per targetConfiguration. (References are resolved once per request, not per reference or relation.)
  • Inline Reference is only permissible if the requested root configuration has Allow Inline Relations set.
  • Every resolution of a Inline Reference counts toward your licensed entities limit unless that entity was previously cached.

Inline Content

Inline Content will resolve the relation and render the referenced entities inline.

Inline Content is the least efficient RenderType. Handle with caution!

Inline Content forces Squid to resolve the relation for each and every entity with an extra SQL query and then resolve the referenced entities with again additional SQL queries. As with Inline Content for references this may cause an extreme amount of queries!

Try it: https://demo.squid46.io/cmdb_ci_server_inline_minimal?encodedQuery=base_name=dbaix901nyc&relations=demo_ci_to_user_group_inline_content

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_inline_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_inline_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_inline_content" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07",
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z",
"user_groups": [ <= relation name
{ <= inlined user group 'Infrastructure'
"active": true,
"name": "Infrastructure",
"sys_created_by": "admin",
"sys_created_on": "2021-03-30T18:56:30Z",
"sys_id": "6577e5908f972410960c53ac37bdee66",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2021-03-30T18:56:30Z"
},
{ <= inlined user group 'CAB Approval'
"active": true,
"description": "CAB approvers",
"name": "CAB Approval",
"sys_created_by": "admin",
"sys_created_on": "2011-09-30T16:30:34Z",
"sys_id": "b85d44954a3623120004689b2d5dd60a",
"sys_mod_count": 0,
"sys_updated_by": "admin",
"sys_updated_on": "2011-09-30T16:30:34Z",
"type": [
"itil"
]
}
]
}
],
"relations": {}, <= relations remain empty
"referenced": {} <= references remain empty
}
  • Inline Content requires a targetConfiguration.
  • Inline Content causes negligible memory load.
  • Inline Content will increase the amount of SQL queries exponentially.
  • Inline Content is only permissible if the requested root configuration has Allow Inline Relations set.
  • Every resolution of a Inline Content counts toward your licensed entities limit unless that entity was previously cached.

Inline Literal

Only available for M-to-N relations

This RenderType only makes sense in an M-to-N Relation where the to column of the relation is something other than a sys_id. Otherwise just use Inline SysId.

Vanilla ServiceNow does not have any use cases for this RenderType, but what do we know what customers might build?

From a purely data architectural perspective, returning the to column of an M-to-N table is valid use case.

We might expand this RenderType to support Relations as that would be valid from a technical point of view, but only if and when customers present a real use case.

Give us a heads-up at Support if you think you need this.

Inline Literal will resolve the relation and render the literal value of the to field inline.

Try it: https://demo.squid46.io/cmdb_ci_server_inline_minimal?encodedQuery=base_name=dbaix901nyc&relations=demo_ci_to_user_group_inline_literal

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_inline_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_inline_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_inline_literal" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07",
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z",
"user_groups": [ <= relation name
"6577e5908f972410960c53ac37bdee66", <= the value in the 'to' column of the relation
"b85d44954a3623120004689b2d5dd60a" <= the value in the 'to' column of the relation
]
}
],
"relations": {}, <= relations remain empty
"referenced": {} <= references remain empty
}
  • Inline Literal does not require nor support a targetConfiguration.
  • Inline Literal causes no memory load.
  • Inline Literal will cause one additional SQL per entity.
  • Inline Literal is only permissible if the requested root configuration has Allow Inline Relations set.
  • Inline Literal relations do not count toward your licensed entities limit.

Inline Display Value

Inline Display Value will resolve the relation and render the display value of the referenced entity inline.

As the returned values are potentially localized, this introduces a level of variance that is usually dangerous for technical integrations.

This is probably NOT what you want

While there may be legitimate use cases for Display Value (see examples mention in References Display Value), the rendered value can be dependent on the locale of the caller. This might lead to unexpected results.

Try it: https://demo.squid46.io/cmdb_ci_server_inline_minimal?encodedQuery=base_name=dbaix901nyc&relations=demo_ci_to_user_group_inline_display_value

Response
{
"metadata": {
...,
"config": "cmdb_ci_server_inline_minimal", <= requested configuration
"requested_relations": { <= requested relations
"cmdb_ci_server_inline_minimal": [ <= configuration the relations were requested for
"demo_ci_to_user_group_inline_display_value" <= requested relation
]
},
...
},
"data": [
{
"asset_tag": "P1000182",
"last_discovered": "2024-07-12T11:21:50Z",
"name": "dbaix901nyc",
"sys_class_name": "cmdb_ci_unix_server",
"sys_id": "5f9b83bfc0a8010e005a2b3212c9dc07",
"sys_mod_count": 22,
"sys_updated_on": "2025-12-24T13:57:32Z",
"user_groups": [ <= relation name
"Infrastructure", <= the display value of the user group
"CAB Approval" <= the display value of the user group
]
}
],
"relations": {}, <= relations remain empty
"referenced": {} <= references remain empty
}
  • Inline Display Value does not require nor support a targetConfiguration.
  • Inline Display Value causes no memory load.
  • Inline Display Value will cause one additional SQL per entity.
  • Inline Display Value is only permissible if the requested root configuration has Allow Inline Relations set.
  • Inline Display Value relations do not count toward your licensed entities limit.
We track. Ok?