SuiteScript
SuiteScript questions test whether you can pick the correct script type and entry point, live within governance, and know which APIs are legal in which context. The exam is less about syntax than lifecycle: when code runs, what it may touch, and what happens when it fails.
Types and entry points
- User Event (server): beforeLoad, beforeSubmit, afterSubmit - one record at a time.
- Client (browser): pageInit, saveRecord, validateField, fieldChanged, postSourcing, lineInit, validateLine, validateInsert, validateDelete, sublistChanged.
- Scheduled: execute. Map/Reduce: getInputData, map, reduce, summarize.
- RESTlet: get, post, put, delete or custom function names. Suitelet: onRequest.
Client scripts operate on N/currentRecord, not N/record; loading arbitrary records in the browser is not the client model. Server scripts should batch: one search plus targeted loads beats a loop of record.load, and record.transform beats rebuilding lines by hand.
Governance
Each execution receives a pool of units - most synchronous types start at 1,000, while scheduled scripts get a larger pool. API calls deduct units, searches and record loads being the expensive ones. script.getRemainingUsage() lets you checkpoint, and N/runtime exposes the current script and user.
Worked example. A scheduled script updating 60,000 item records times out and logs an SSS_TIME_LIMIT error. Reasoning: a single execute entry point cannot finish the volume, and throwing more governance at it does not fix the architecture. Move to Map/Reduce: getInputData returns a search, map processes each key independently, reduce aggregates, and summarize writes the report. A failing key is retried and logged without aborting the whole job.
Traps
- Assuming afterSubmit can block a save - throwing there logs an error but the record is already committed; beforeSubmit is the gate.
- Calling
N/recordfrom a client script. - Forgetting that RESTlet function names become the external entry points, so the deployment and URL must match.