Custom Table Query Not Returning Results on Customer Instance - Zurich Release

[Haridas_Pawar]

Hi Community,

We have an application published on the ServiceNow Store that is in use by our end customers. However, for one specific customer, we are facing a puzzling issue that we are unable to debug.

We have custom tables created in our application to store credentials. These custom tables extend from the Credentials table (discover_credential). We have Script Include functions that are responsible for fetching records from this table based on the TSG ID. Attaching a sample code for your reference:

try {
    var snowConf = {
        "username": "",
        "password": ""
    };

    var gr = new GlideRecordSecure("[CUSTOM_TABLE_NAME]");
    gr.addQuery("active", true);
    gr.addQuery("sys_id", "5dfa85661b08cb9074762f4a234bcbfc");
    gr.query();
    if (gr.next()) {
        snowConf.username += gr.servicenow_instance_username;
        var snowPassword = gr.servicenow_instance_password;
        snowConf.password = snowPassword.getDecryptedValue();
    } else {
        gs.warn("[Debug Script] - No active configuration found.");
    }

    gs.info("[Debug Script] Credentials retrieved successfully.");
} catch (ex) {
    gs.error("[Debug Script] - Error: Unable to fetch credentials " + ex.toString());
}

Environment Details:

Customer Instance Version: Zurich release

Debugging Steps We've Tried:

Executed the above script from a Fix Script to test if the script is working on the customer's vendor instance - but it is not working.

Executed the above script from a Scheduled Job that falls under our custom application scope - still not working.

Issue Summary:

The query returns zero results when executed on the customer's instance.

The same script works perfectly on other customer instances and our development instances.

Admin users are also unable to fetch records through this query.

Questions:

1. Has anyone ever experienced this issue, especially on the Zurich release?

2. What could be the possible root cause and resolution for such scenarios?

3. Are there any known platform issues or system properties in the Zurich release that could affect GlideRecordSecure queries on tables extending from discover_credential?

Any guidance or suggestions would be greatly appreciated.

Thank you in advance!

[Vikram Reddy]

Hi @Haridas_Pawar,

This isn't a Zurich-specific bug, it's almost certainly an ACL evaluation difference on that one instance. Zero rows for admins too is the real clue: GlideRecordSecure enforces ACLs while plain GlideRecord doesn't, and tables extending discover_credential inherit the parent table's ACLs unless you've explicitly overridden them on your custom table. If that customer instance has the High Security Settings plugin (com.glide.high_security) active, ACL evaluation switches to default-deny, and any ACL scoped to security_admin only grants access when the session has actually elevated to that role. Scheduled Jobs and Fix Scripts don't carry an elevated security_admin context automatically, even when the running user technically holds the role, so a query that works fine for an interactively-elevated admin can silently return nothing from a background script.

Pull up sys_security_acl for both discover_credential and your extended table on that instance and diff the roles and condition scripts against your dev instance. Confirm whether High Security Settings is active under System Definition > Plugins. Then set glide.security.debug to true, or use System Diagnostics > Session Debug > Debug Security, and re-run the query interactively as an elevated admin, the debug output will name the exact ACL that's denying the read.

Thank you,
Vikram Karety
Octigo Solutions INC