Extending the GlideRecord Prototype - ben-vargas/servicenow-wiki GitHub Wiki

GlideRecord is a core API that facilitates reading and manipulating records in ServiceNow’s database. By default, it provides a robust set of methods suited for most use cases. However, some developers may consider extending its prototype to introduce custom functionalities. This approach, while technically possible, is not officially supported and can pose serious risks to system stability, maintainability, and support.

Important Warning

Extending the GlideRecord prototype is strongly discouraged and should be undertaken only as a last resort. Potential consequences include:

  • Support Limitations: ServiceNow may refuse support if issues arise due to custom modifications of internal APIs.
  • System Instability: Overriding or misconfiguring prototype methods can break core logic, disrupt business rules, or produce unpredictable behavior throughout the platform.
  • Upgrade and Compatibility Risks: Undocumented internal behaviors may change in future releases, rendering custom extensions invalid or harmful after an upgrade.

Proceed at your own risk, and only after thorough testing in a development or test instance.

Before You Begin

  1. Is this absolutely necessary?
    Before modifying the prototype, consider alternative solutions:

    • Script Includes or utility classes that wrap GlideRecord functionality.
    • Scoped applications and separation of concerns to avoid modifying a global class.
    • Existing GlideRecord methods that might achieve the same results.

  2. Testing Environment:
    Never implement this in production without extensive testing in a sandbox or development environment.

  3. Change Management:
    Document every change, including rationale, code snippets, and potential side effects. This is critical for future troubleshooting and maintenance.

How to Extend the GlideRecord Prototype (If You Must)

Step 1: Temporarily Disable Client Script Restrictions

Out-of-the-box, ServiceNow prevents code outside functions in Business Rules. To bypass this temporarily:

  1. Elevate Privileges: Make sure you have the security_admin role.
  2. Disable the "Don't allow code outside functions" Client Script:
    Navigate to the relevant client script and disable it to allow defining prototype code at the global level.

Re-enable this script after making your changes to maintain a secure and predictable environment.

Step 2: Create a Global Business Rule for the Prototype Extension

Create a global Business Rule that runs on "Before Query" or a similar event that always executes on server load. In the Script field, define your custom methods:

// Example: Add a custom property and function to GlideRecord
// This code runs globally, outside a function, and modifies GlideRecord's prototype.

GlideRecord.prototype.hello = 'Hello Community!';

GlideRecord.prototype.isMultipleOf = function(field, multiple) {
    var value = parseInt(this[field], 10);
    return !isNaN(value) && (value % multiple === 0);
};

Tips:

  • Unique Naming:
    Use clear, unique names to avoid clashes with existing methods. Consider prefixes like my_ or ext_ to distinguish custom methods.

  • Minimalism:
    Add only what you truly need. The more extensive your modifications, the higher the risk.

Step 3: Use Your Extensions Cautiously

You can now call your custom property and function in server-side scripts:

function onBefore(current, previous) {
    // Example usage of the custom property
    gs.addInfoMessage(current.hello);

    // Using the custom function
    var multiple = parseInt(current.urgency, 10);
    var isMult = current.isMultipleOf('impact', multiple);
    gs.addInfoMessage('Is impact a multiple of ' + multiple + '? ' + isMult);
}

Best Practices

  • Document Everything:
    Maintain a record of what methods you added, why, and how to revert changes if something goes wrong.

  • Version Control:
    Store this code in a controlled environment. Use comments to indicate when and why changes were made.

  • Avoid Overriding Core Methods:
    Never redefine existing GlideRecord methods, as this can cause widespread breakage.

  • Monitor After Implementation:
    After deploying, monitor logs and system performance. Immediately revert changes if unexpected issues arise.

Alternatives to Extending the Prototype

  • Script Includes or Utility Classes:
    Implement common logic in script includes that accept a GlideRecord object as a parameter. This avoids altering the prototype.

  • GlideRecord Wrapper Functions:
    Write standalone functions that perform operations on a GlideRecord instance. This keeps the core API unchanged.

  • Scoped Applications:
    If you’re working within a scoped app, leverage the isolation provided by scopes to manage custom logic more cleanly.

Conclusion

While it’s technically feasible to extend the GlideRecord prototype, it’s a high-risk practice that can undermine system stability and complicate future maintenance. Consider all alternatives first. If you must proceed, do so carefully, document thoroughly, and prepare for potential challenges in support and upgrades.