Servic

[souravdinka]

 How does dot-walking behave differently in GlideRecord vs GlideForm vs Notifications? Are there limits or pitfalls we should be aware of?

[Saurabh Gupta]

Hi,
Can you please elaborate your question or problem statement?

[Tushar]

Hi @souravdinka 

• GlideRecord: Dot-walking works smoothly to access related fields on the server side.
• For eg, gr.caller_id.manager.name fetches the manager's name from an incident's caller.
• Pitfall: Avoid deep dot-walking (e.g., gr.caller_id.manager.department.location) as it can slow things down or fail if a reference is null.

• GlideForm: On the client side, dot-walking is limited to form fields loaded in the browser. So, g_form.getValue('caller_id.manager.name') won’t work—use g_form.getReference('caller_id', callback) to fetch related data dynamically.
• Pitfall: impact performance

• Notifications: Dot-walking in email scripts works with current or email objects, like ${current.caller_id.manager.email} to get a manager's email.
• Pitfall: It fails if the field isn’t loaded (e.g., due to ACLs) or if the chain breaks—always add checks like ${current.caller_id.manager?current.caller_id.manager.email:'N/A'}

try to add if checks or getValue()/getDisplayValue() to avoid crashes.

Thanks,

Tushar

[Ankur Bawiskar]

@souravdinka 

what's your requirement actually?

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Shraddha Kadam]

Hello @souravdinka ,

Let's break down the differences and considerations for each:

GlideRecord (Server-Side Scripting: Business Rules, Script Includes, Workflows)

How it behaves:

When you dot-walk with GlideRecord, you are essentially instructing the system to perform joins or additional queries to retrieve data from related tables. For example, incidentGR.caller_id.name will first retrieve the caller_id (which is a reference to the sys_user table), and then retrieve the name from that sys_user record.

GlideRecord has full access to all fields on the related record, subject to ACLs (Access Control Lists).

Each dot in a dot-walk chain (e.g., incident.caller_id.location.country) typically represents an additional database lookup or join.

Limits and Pitfalls: 

Excessive dot-walking (many levels deep, or on a large number of records) can lead to performance issues due to multiple database queries.

Recommendation: While there's no strict hard limit on dot-walk levels, a common best practice is to limit it to 3-4 levels for optimal performance, especially when querying multiple records. For deeper levels or complex queries, it's often more efficient to perform separate GlideRecord queries and then link the data in your script.

GlideForm (Client-Side Scripting: Client Scripts, UI Policies)

How it behaves:

Client-Side Representation: g_form works with the data that is currently loaded on the client (browser). When you dot-walk using g_form, it's primarily accessing values that are already available on the form.

Display Values: g_form.getValue() for a reference field returns the sys_id. To get the display value (e.g., the user's name for a caller field), you would typically access the g_form.getDisplayBox('field_name').value or use g_form.getReference() in an asynchronous callback.

Limited Dot-Walking: Direct dot-walking on g_form.field_name.related_field_name isn't as straightforward or universally supported as with GlideRecord. You typically get the sys_id of the reference field, and then you'd need a separate GlideAjax call to the server to get details of the referenced record.

Example: var callerSysId = g_form.getValue('caller_id');

To get the caller's email, you would then need to use GlideAjax to query the sys_user table.

Limits and Pitfalls:

If you need data from a related record that isn't already on the form, you'll need to use GlideAjax to make an asynchronous call to the server. This means you can't get the data immediately, and your script logic needs to handle the callback.

While g_form itself doesn't perform direct database queries for dot-walking, misusing it (e.g., making many GlideAjax calls for simple dot-walks) can still impact client-side performance and user experience.

You can only dot-walk to fields that are visible or available on the current form. If a related field isn't part of the form layout, g_form won't have immediate access to it.

Notifications (Email Scripts, Notification Content)

How it behaves:

Notifications are processed server-side. When you use dot-walking in a notification template (e.g., ${current.caller_id.name}), it behaves similarly to GlideRecord in that it fetches the related data from the database.

ServiceNow uses specific syntax (${current.field_name.related_field_name}) to facilitate dot-walking directly within email templates.

Email Scripts: For more complex logic or to fetch data that's more than a few levels deep, you often use Email Scripts within notifications. Email scripts run server-side and have access to current (the triggering record) and can use GlideRecord to perform more elaborate queries and dot-walking.

Limits and Pitfalls:

Just like GlideRecord, excessive dot-walking in notification templates or email scripts can impact the performance of the notification engine, potentially delaying email delivery.

If a dot-walked field is null or empty, it will simply appear blank in the notification. This can lead to confusing or incomplete emails.

Best Practice: 

For critical fields or deep dot-walks, it's often better to use an Email Script to control the output and add conditional logic to handle missing data gracefully.

When you dot-walk, ServiceNow usually provides the display value of the referenced record in the notification. For example, current.caller_id will show the caller's name, not their sys_id. If you need the sys_id, you might have to explicitly get it within an email script.

Document Fields: 

Dot-walking typically works with reference type fields. It may not work as expected with "Document" type fields. You might need an email script for those.

Debugging: 

Debugging dot-walking issues within notifications can be trickier than in scripts. You often rely on the email log and preview features to see the rendered output.

General Dot-Walking Best Practices & Considerations

Always have a clear understanding of the table relationships and data model before dot-walking.

Prioritize Performance: 

Especially in server-side scripts and notifications, be mindful of the performance implications. Avoid excessive or very deep dot-walks if alternative, more efficient methods (like separate GlideRecord queries with addQuery and addExtraField) exist.

Handle Nulls: 

Always account for the possibility of null or empty reference fields in your dot-walk chain to prevent errors or incomplete data.

Use gs.log() (server-side): 

For debugging, use gs.log() to print out intermediate values of your dot-walked fields to verify the data you are retrieving.