What It Does
The canRead() method performs a read access control check against the current record without triggering an Access Control Exception. ServiceNow evaluates all applicable ACL rules for the table and record, considering the user's roles, groups, and any conditional ACL logic, then returns a simple boolean result.
Internally, the platform runs through the same ACL evaluation process that would occur during a normal query or get() operation, but instead of either returning the record or throwing an exception, it simply returns the access determination. This includes evaluating table-level ACLs, field-level read ACLs, and any script-based conditional logic within those ACL rules.
The method returns true if the user has read access and false if access is denied. It never returns null or undefined, making it safe for direct boolean evaluation. The method works on both existing records (where you've called get() or are iterating with next()) and on new record objects before insertion.
The method only checks READ access. It does not validate write, delete, or create permissions.
Edge cases include scenarios where the GlideRecord is pointing to a non-existent record (returns false), when called on a GlideRecord that hasn't been initialized with a table name (throws an error), or when used with records that have been deleted during the current transaction. The method respects domain separation and will return false for records outside the user's domain scope.
This method pairs with canWrite(), canCreate(), and canDelete() to provide comprehensive permission checking. Unlike get() or query operations that filter out inaccessible records silently, canRead() gives you explicit visibility into access decisions.
When to Use This
Use canRead() when you need to make decisions based on whether a user can access specific records before performing operations that might fail or expose sensitive information. This is particularly valuable in Script Includes that serve multiple callers with different permission levels, Business Rules that process records on behalf of various users, and REST APIs where you want to return appropriate HTTP status codes rather than throwing server errors.
Avoid using this method for routine queries where you simply want to retrieve accessible records. Use standard GlideRecord queries instead, which automatically filter based on ACLs and perform better. Also avoid it for field-level access control—use GlideRecord.canReadField() for that purpose. Don't use canRead() as a substitute for proper ACL configuration—it's a tool for working with existing ACLs, not bypassing them.
Return Value
Returns a boolean value: true if the current user has read access to the record, false if access is denied for any reason. The return value is always a proper boolean, never a string representation like "true" or "false", and never null or undefined, making it safe for direct use in conditional statements and boolean operations.
When the record doesn't exist, the user lacks proper roles, or domain separation prevents access, the method returns false rather than throwing an exception. This consistent behavior allows you to use it safely in conditional logic without wrapping it in try-catch blocks, unlike direct record access operations that might throw ACL exceptions.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.
Platform Behavior & Side Effects
- Executes ACL rule evaluation including any script-based conditions, but does not fire Business Rules or other record-level events
- Makes no database writes or modifications—purely a read-only permission check operation
- Performance is moderate since it runs full ACL evaluation, but faster than actual record retrieval as no field data is loaded
- ACL results may be cached by the platform, so repeated calls on the same record within a transaction can be faster
- Works consistently across different contexts (Business Rules, Script Includes, Scheduled Jobs) but always uses the current user's permissions
- Does not generate audit entries or security logs, unlike failed attempts to access restricted records through normal queries
- Respects elevated privilege contexts—returns true for admin users or when running with elevated privileges via gs.setElevated()
