GlideRecordSecure | GlideRecord vs GlideRecordSecure | When to use GlideRecordSecure

[Ishaan Shoor]

Are you using GlideRecordSecure in your ServiceNow scripts? 

I recently stumbled upon a question about GlideRecordSecure and how it differs from GlideRecord. Although I had heard of GlideRecordSecure before, I never delved deeper or used it.

In order to gauge its usage in the ServiceNow community/ecosystem, I conducted a LinkedIn poll and found that 89% of the respondents have either used it occasionally, never used it, or have not even heard of it.

GlideRecordSecure is a variant of GlideRecord that provides enhanced security features. In a nutshell, it allows you to control access to data, preventing unauthorized users from viewing or modifying sensitive information by enforcing access controls. So why aren't more people using GlideRecordSecure? One possibility is that many ServiceNow developers simply aren't aware of its existence, Another is that it may not be necessary for all the use cases.

Regardless of your current usage of GlideRecordSecure, it's worth understanding GlideRecordSecure better, the differences between GlideRecord and GlideRecordSecure, and when to use each, Let's explore these topics further in this blog.

Overview

GlideRecord and GlideRecordSecure are two of the most commonly used scripting classes in ServiceNow, both of which are used to interact with the ServiceNow database.  GlideRecord is a ServiceNow API that allows developers to access and manipulate data in ServiceNow databases. GlideRecordSecure is another version of GlideRecord that provides an additional layer of security. 

What is GlideRecord?

GlideRecord is a ServiceNow API that provides developers with an easy way to query, update, and insert data into ServiceNow tables. GlideRecord allows developers to perform complex queries, and filter data based on a variety of conditions. GlideRecord queries can return one or more records, which can then be used to perform further operations.

What is GlideRecordSecure?

GlideRecordSecure is a version of GlideRecord that provides an additional layer of security. GlideRecordSecure is designed to prevent unauthorized access to data. GlideRecordSecure enforces access controls and ensures that the user has permission to access the records they are querying. Developers can then use GlideRecordSecure in the same way as GlideRecord to query and manipulate ServiceNow records. 

What are the differences between GlideRecord and GlideRecordSecure?

GlideRecord queries and manipulates data in the same way as GlideRecordSecure, but GlideRecordSecure provides additional features for securing sensitive data. This ensures that sensitive data cannot be intercepted by unauthorized users as it enforces access controls.  Another difference between the two is performance, Because GlideRecordSecure enforces access controls, it may take longer to execute queries than GlideRecord.

When to use GlideRecord vs GlideRecordSecure?

If you are accessing, querying, or manipulating data that is not sensitive and do not need to enforce access controls, you can use GlideRecord. If you are accessing sensitive data and need to enforce access controls, It's a good idea to use GlideRecordSecure, This will help ensure that the data remains secure and confidential and that only authorized users can access it. 
  
Conclusion

GlideRecord and GlideRecordSecure are both useful classes in ServiceNow for interacting with tables. GlideRecord is a convenient way to query tables, while GlideRecordSecure enforces access controls and ensures that the user has permission to access the records they are querying. GlideRecord is ideal for general-purpose queries and manipulations of non-sensitive data, while GlideRecordSecure is designed to be used when working with sensitive data.

Some other blogs and videos for your reference that you can have a look at are below

GlideRecord vs GlideRecordSecure by Brittany Navin
GlideRecordSecure vs GlideRecord | ServiceNow - YouTube by @Community Alums 
Learn ServiceNow GlideRecordSecure | GlideRecordSecure vs GlideREcord- YouTube  by @Amit Gujarathi 

GlideRecordSecure 
 

If you have any feedback, suggestions, or additional references that can enhance the blog, feel free to let me know.

Regards,
Ishaan

[Community Alums]

Thanks for the insight @Ishaan Shoor !

[sailesh1]

Thanks for the article @Ishaan Shoor 
Just a thought, Can we then use GlideRecordSecure API more than query BRs to restrict access to records?

[Ishaan Shoor]

Hi @sailesh1,

I think your question is  "can  we use GlideRecordSecure API instead of query BRs?", if that's correct.
GlideRecordSecure API is not used to replace business rules or so, rather it's used as a part of the server script in various server side scripting in ServiceNow, now this script can be a part of Business rule script, Script includes, background-scripts, widgets and the list goes on. 

If you're asking that we should use GlideRecordSecure more in business rule scripts instead of standard GlideRecord?
GlideRecordSecure supports similar functions/rules as GlideRecord but gives additional security by automatically enforcing the security rules defined in the Access Control Rules (ACLs) to ensure that only authorized users can perform the requested actions. where as you'll have to call additional methods to do this check using GlideRecord. So, if you need to ensure that a user has read/write/delete access to data in a script, GlideRecordSecure is the way to go, otherwise you can use GlideRecord and if you're not sure you can still go with GlideRecordSecure as it does the job with added security 🙂 

Hope this answer your question, please let me know if you have any more questions. 

Regards,

[sailesh1]

Thank you @Ishaan Shoor 
I think I have scrambled the wording, Nevertheless I found what I am looking for in the latter part of your answer.

Cheers!

[Amit Gujarathi]

Thanks @Ishaan Shoor for the credits...

[kalpesh9]

Really Helpful..!! Thank you @Ishaan Shoor 

[b__YogeshKumarD]

Very Help!!! Great addOn to my knowledge....

[Lisa71]

Then using gliderecord API, the developer can allow anyone to access any data even the developer him/herself doesn't have access to that table, right?