Limit GlideRecord query results

The setLimit() method exists because ServiceNow will happily return millions of records if you let it, and your transaction will timeout, memory will spike, and users will blame you for the outage. Without explicit limits, a seemingly innocent query like addQuery('active', true) becomes a production incident when it pulls 800,000 task records. The platform doesn't protect you — you must protect yourself.

When to use setLimit()

• Processing records one-by-one in business rules where you know the expected volume
• Scheduled jobs that process batches of records to avoid transaction timeouts
• Fix scripts where you're testing logic on a subset before full deployment
• Any query where the result set could grow unpredictably over time

When NOT to use setLimit()

• When you only need a count — use GlideAggregate with addAggregate('COUNT') instead
• When you need to guarantee processing ALL matching records — use choiceLimit system property instead
• In client scripts — you can't, and you should use GlideAjax to call server-side code instead
• Inside loops over other GlideRecord results — you'll create N+1 query performance problems

Key behaviors and gotchas

• Call setLimit() AFTER all addQuery() calls — calling it first can cause unpredictable results
• The platform default limit is typically 10,000 records, but this varies by table and can change without notice
• Combine with orderBy() to get consistent results — without ordering, you get random records within the limit
• Performance degrades exponentially beyond 1,000 records in a single transaction — use smaller limits for business rules
• ACLs still apply to limited results — you might get fewer records than your limit if access is restricted
• Domain separation can further reduce results — each domain sees only its own records within the limit