Identify whether the data you need crosses record-type boundaries (multi-table joins favor SuiteQL) or is already captured in an existing saved search
For SuiteQL: assess whether all required fields are exposed in the SuiteQL schema (check the Schema Browser); not every NetSuite field is SuiteQL-accessible
For Saved Search via REST: use the SuiteQL workaround by querying the 'SavedSearch' virtual table or retrieve results via SuiteScript N/search if running server-side
Benchmark both approaches for your expected row volume; saved searches can be faster for simple single-record-type lookups with complex formula columns
Consider maintenance: saved searches are managed in the UI and can be modified by non-developers, while SuiteQL is code-owned and version-controlled
Use SuiteQL for programmatic, version-controlled integrations; use saved searches for ad-hoc UI reporting or when reusing an existing business-defined search
Known gotchas
SuiteQL does not expose every field or subrecord — custom body fields are generally available, but some system-computed fields are absent; validate schema coverage before committing
Saved searches retrieved via REST return results in a fixed format that may differ from the column order shown in the UI, and column IDs may not match field IDs
Both approaches count against REST and script governance limits; high-frequency polling of either can exhaust concurrency limits for shared accounts
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp