SuiteCloud Developer common mistakes
SuiteCloud Developer · Understand the traps and how to avoid them.
Writing a User Event script and assuming the beforeSubmit or afterSubmit entry point fires on every record operation, including when records are created through CSV import or web services, and then debugging a 'missing' trigger as a code bug.
Candidates memorize the four user event entry points but never learn that the execution context (contextType) changes which events fire, and that some contexts suppress certain entry points or run in a restricted governance budget. They test only in the UI, where everything appears to work, so the gap surfaces only under a different invocation path.
What to do instead
Learn the contextType values for user event scripts and which entry points fire in each. When a trigger seems absent, log scriptContext.type and scriptContext.contextType at the top of the entry point before changing any logic. Test the same record operation from the UI, from a scheduled script, and from a web services call so the context differences become concrete rather than theoretical.
Mixing client scripts and server scripts in one mental model: attempting to call NetSuite modules such as N/record or N/search from a client script, or expecting a client script to run during a scheduled or RESTlet execution.
Both are 'SuiteScript' and the syntax looks similar, so candidates assume any module is available anywhere. The exam deliberately probes the boundary between the client (browser) sandbox and the server sandbox, and candidates who never wrote a client script against a real record miss that only a small subset of modules and no direct database access exist client-side.
What to do instead
Build a two-column reference of client-only concerns (pageInit, fieldChanged, saveRecord, validateField, client-side N/https or N/url calls to a RESTlet) versus server-only concerns (N/record, N/search, N/file, N/task). For any cross-boundary need, the answer is usually a RESTlet or Suitelet called from the client script, not a direct module call.
Treating governance units as a single undifferentiated budget: assuming a scheduled script, a map/reduce script, and a RESTlet all get the same allocation, or that governance is only relevant to long-running scripts.
The governance model differs by script type and by deployment, and candidates study the number '1000' in isolation without learning which script types get which limits or how yield and rescheduling interact with the remaining budget. Questions that ask why a script terminates partway are usually governance questions in disguise.
What to do instead
Memorize the governance allocation per script type and per deployment context, then practice reading a script that fails at record 500 and identifying whether the cause is governance exhaustion, a yield requirement, or a hard limit. Learn the difference between governance units and usage units (such as search or file limits) so you do not attribute one failure to the other.
Assuming a saved search returns every matching record and building logic that depends on a complete result set, then discovering the script silently processed only a subset.
Saved searches and search module queries are subject to result caps and pagination behavior that differ between script contexts and the UI. Candidates who only ever ran small searches in a sandbox never hit the cap, so they do not recognize the symptom of a truncated result set when the exam describes it.
What to do instead
Learn the search result limits and the pagination pattern (start and result set size, looping until fewer than the page size is returned). When the requirement is 'process all matching records', prefer map/reduce or a paged search loop rather than a single search call, and be able to explain why.
Confusing custom record types, custom segments, and custom fields when choosing where to store data, and then writing scripts that reference the wrong record type identifier.
The customization domain presents many similar-sounding objects, and candidates who have not built each one treat them as interchangeable. They also miss that the internal ID of a custom object is not the same as its script ID, which produces script errors that look like typos.
What to do instead
Build a decision table: custom record type for new entities with their own records, custom segment for a new classification dimension on existing records, custom field for a single attribute. Practice referencing each by script ID in a script and confirm in the UI which identifier the script actually needs.
Deploying a script without configuring the deployment record correctly: wrong status, wrong audience, wrong log level, or missing the record type and event selection, then concluding the script is broken when it simply never executes.
The script file and the deployment are separate objects, and candidates who have only uploaded files in a sandbox often skip the deployment step or accept defaults. The exam tests whether you understand that deployment controls execution, not the script code itself.
What to do instead
Treat 'upload, create script record, create deployment, set status to released, set audience and log level' as a fixed checklist, and be able to state what each setting changes. When a deployed script does not run, verify the deployment status and audience before touching the code.
Using SuiteScript where declarative customization would suffice, or the reverse, and failing questions that ask for the appropriate tool for a requirement.
Candidates over-index on the language they know best. The exam frequently frames a requirement (for example, conditionally showing a field or enforcing a validation) and expects the simplest supported mechanism, which is often a workflow, a validation rule, or a field-level setting rather than a script.
What to do instead
For each requirement, ask in order: can a standard setting do this, can a workflow do this, does this need server-side logic, does this need client-side behavior. Learn the specific cases where workflows and scripts overlap and which is preferred for maintainability.
Misunderstanding SuiteCloud Development Framework project structure: placing objects in the wrong directory, forgetting the manifest or deploy.xml, or assuming an SDF project deploys objects that were never added to it.
SDF is file-and-folder based and the exam tests the mechanics of account customization projects versus suiteapp projects. Candidates who have only used the UI-based customization workflow never internalize that the project contents, not the account, determine what gets deployed.
What to do instead
Learn the directory layout for each object type, the role of the manifest and deploy configuration, and the difference between importing an object into a project and creating one. Practice a round trip: import an object, change it in the project, deploy, and observe what changed in the account.
Treating RESTlets and Suitelets as interchangeable integration endpoints, or ignoring authentication and request-method handling when describing an integration design.
Both are server-side entry points reachable over HTTP, so the distinction blurs for candidates who have not implemented either. They also forget that RESTlet behavior depends on the HTTP method and that token-based authentication must be configured, which the exam probes in integration scenarios.
What to do instead
Write down the purpose of each: RESTlet for programmatic record operations over HTTP with method-based dispatch, Suitelet for server-rendered pages and file delivery. For any integration question, state the authentication mechanism, the request and response format, and the error handling path explicitly.
Answering questions about script execution order and record lifecycle from intuition rather than from the documented sequence, for example assuming a client-side field validation runs before a server-side user event or that afterSubmit runs before the record is committed.
The lifecycle spans client and server phases and multiple entry points, and candidates who have not traced a real save operation with logging guess at the order. Small ordering errors change which answer is correct on questions about validation, defaults, and side effects.
What to do instead
Trace one record save end to end with log statements in pageInit, fieldChanged, saveRecord, validateField, beforeLoad, beforeSubmit, and afterSubmit, and record the observed order. Memorize which phase can still block the save and which runs after commit, since that distinction drives most lifecycle questions.