How to fix it

  1. Navigate to System Definition > Tables and open your target table to verify all field references in your encoded query exist on this specific table.
  2. Copy your encoded query into a text editor and search for javascript: to identify any dynamic functions that need replacement.
  3. Replace date functions with static values. For example, change javascript:gs.beginningOfLastMonth() to 2024-01-01 or calculate the date value in your script first.
  4. For user-relative functions, replace javascript:gs.getUserID() with the actual user sys_id or calculate it separately in your script using gs.getUserID().
  5. Open System Logs > System Log > All and add debug logging to your script: gs.log('Query: ' + encodedQuery, 'DEBUG');
  6. Test your corrected encoded query in a background script first. Go to System Definition > Scripts - Background and run a simple query to verify results.
  7. For complex OR conditions, wrap them in parentheses manually. Change field1=value1^ORfield2=value2^field3=value3 to (field1=value1^ORfield2=value2)^field3=value3 if needed.
  8. Check if your business rule runs as system user by examining the Advanced tab. If so, user-based queries will behave differently than in the UI.
  9. Use gs.log(gr.getEncodedQuery(), 'DEBUG') after building your GlideRecord to see the final resolved query and compare it with your original.
  10. For date-sensitive queries, calculate the date values in your script before building the query: var startDate = gs.beginningOfLastMonth(); gr.addQuery('created', '>=', startDate);
💡

Always test encoded queries in Scripts - Background before using them in business rules. Copy the exact query string and log the record count to verify it matches your expectations.