Transaction quota exceeded: script consumed too many resources

Inefficient GlideRecord queries without proper filtering, such as querying large tables without where clauses or using addQuery() with OR conditions on non-indexed fields. (high likelihood)

Infinite or excessive loops in Business Rules, Script Includes, or scheduled scripts that process large datasets without pagination or chunking. (high likelihood)

Multiple nested GlideRecord queries or queries within loops that exponentially increase database row fetches beyond the transaction limit. (medium likelihood)

Excessive external HTTP calls using RESTMessage or SOAPMessage within a single transaction without proper batching or async processing. (medium likelihood)

Complex dot-walking operations on reference fields that trigger multiple database queries, especially in large result sets or calculated fields. (low likelihood)

Step 1: Navigate to System Diagnostics > Log > Application Log and search for the exact timestamp and source of the quota exceeded error to identify the specific script causing the issue.

Step 2: Review the Transaction Log Stats in the error details to determine which resource quota was exceeded: database rows fetched, script execution time, or HTTP calls.

Step 3: Examine the identified script for inefficient GlideRecord queries and add proper where clauses, indexed field filters, or setLimit() calls to reduce the number of rows processed.

Step 4: Implement pagination using chooseWindow() or query.setLimit() with offset processing for scripts that need to process large datasets, breaking work into smaller transactions.

Step 5: Replace nested queries or queries within loops with single optimized queries using addQuery() with proper join conditions or aggregate GlideAggregate queries where appropriate.

Step 6: For external HTTP calls, implement batching mechanisms or move the calls to Scheduled Jobs with async processing using gs.eventQueue() to distribute the workload.

Step 7: Test the optimized script in a sub-production environment and monitor the Transaction Log Stats to verify resource consumption stays within limits.

Step 8: Consider moving resource-intensive operations to Scheduled Jobs, Flow Designer, or Event-driven architecture if the script cannot be optimized to fit within transaction limits.