Check copied values in a NetSuite SuiteScript 2.0 exercise

The quick answer

A primitive variable read before setValue keeps its earlier value. A watch of that variable and a log that uses it can stay empty while the record field changes. Step through the setters in this local exercise, finish its modeled save, then perform a fresh local record read. Verify an actual account after the real save completes.

Before you start

These screenshots show an executable local exercise based on the legacy in-page SuiteScript 2.0 debugger. They do not establish a NetSuite server execution. The exercise saves its pending local Customer after successful completion; its stop/discard rule does not establish rollback behavior in NetSuite.

For an actual account, prepare an existing Customer User Event whose Script record identifies the beforeSubmit entry point and whose Customer deployment is in Testing. The tester must be the assigned script owner. Verify SuiteScript = Full, Customer and custom-field access, deployment audience and execution contexts. Use a controlled record, preferably in a sandbox or release preview. An actual-account debugger session uses that account’s data. This local exercise establishes no account-data mutation. Deployment creation, changing production deployment status and file upload are outside this guide.

Coupon Code is a configured stored custom entity field applied to Customer. Its illustrative internal ID is custentity_coupon_code; verify the account’s actual ID, type, Customer applicability, Store Value setting and permissions. Form visibility is needed for the visual check here, not for a script to persist the value.

Names are illustrative: Alex Morgan, Example Supply Co. and customer 401 Alder Equipment. The example starts with empty Comments and Coupon Code. SuiteScript 2.1 uses a different Chrome DevTools workflow; these controls are for the legacy 2.0 interface.

01. Arm the existing script

Open Script Debugger, confirm API Version 2.0, and select Debug Existing. In an actual account, the usual navigation is Customization > Scripting > Script Debugger.

Choose Customer Field Review and activate Select and Close. This exercise’s eligible modeled Testing deployment is already configured; the list is not proof that an arbitrary account deployment is ready.

The Debug Existing list contains Customer Field Review, a User Event applied to Customer. — Select the exercise’s modeled Customer User Event, then activate Select and Close.

Confirm Waiting for User Action. The script is armed, but the triggering Customer action has not yet been received.

The legacy debugger displays Waiting for User Action. — The exercise is waiting for its triggering Customer action.

02. Trigger beforeSubmit

Use Global Search to open Alder Equipment. Its Comments and custom Coupon Code begin empty. Click Edit, then Save to invoke the modeled Customer beforeSubmit.

Customer 401 Alder Equipment is open in View mode with an Edit action. — Open the exercise’s controlled Customer before Edit and Save.

The local exercise returns to its paused debugger. In the real legacy workflow, keep the debugger open and perform the Customer action in another debugger-domain tab or window. That account-level workflow is separate from this local exercise; a real Customer save can change account data.

03. Inspect the copied value

Set a breakpoint on the first setValue statement, then choose Continue. Execution pauses before that setter; the earlier reads have already populated the variables. Open Local Variables: comments and couponCode contain the earlier empty strings.

Local Variables shows comments and couponCode as empty strings. — The exercise shows primitive values read before the setters run.

For account code, use the documented options-object forms of Record.getValue and Record.setValue. The recording preserves its source’s positional call forms in a bounded local exercise; it does not validate API compatibility in an account. The same read-then-write relationship is:

var comments = customer.getValue({
    fieldId: 'comments'
});
customer.setValue({
    fieldId: 'comments',
    value: 'Preferred contact: email.'
});

Here customer is context.newRecord. In a real beforeSubmit, its field changes participate in the originating save; this example calls no additional save() on that object.

comments is a primitive copy. The setter updates the record object; it does not assign a new value to that variable.

Open Watches, enter comments in Add Watch, and press Enter. Choose Step Over for each of the two setter statements. The watch still reads an empty string because it evaluates the earlier variable, not a fresh field read.

After both setter statements, the comments watch still displays an empty string. — In this exercise, the earlier comments variable stays empty after the setters.

The second setter assigns SUMMER25 to this example’s configured custom Coupon Code field. This is a stored text value, not a demonstrated discount or coupon-redemption action.

04. Read the saved fields

Choose Continue and confirm the exercise’s Completed Deployed Script Execution label. The local model now commits its pending Customer. This models the local save only; the reconstructed status does not prove that an account save committed.

On Execution Log, the Copied comments and Copied coupon messages still use the earlier variables. They show the earlier empty variable values, rather than fresh reads from the record object. A message proves what the code emitted, not persistence. In a real 2.0 run, this subtab contains server messages; here the messages are emitted by the local model.

The modeled Execution Log lists Original comments, Copied comments, Copied coupon and Code complete without appended values. — The local Copied messages use earlier variables rather than fresh field reads.

Open Alder Equipment again through Global Search. The fresh local record read shows Comments: Preferred contact: email.

The saved local Customer Comments field reads Preferred contact: email. — A fresh local Customer read shows the updated Comments value.

The custom Coupon Code reads SUMMER25.

The saved local Customer custom Coupon Code field reads SUMMER25. — The configured Customer entity field also contains its new value.

In an actual account, verify the saved record after the save completes. Validation, permissions, errors and other automation can prevent or alter the result. Neither a setter alone nor an emitted log proves persistence.

Common questions

Why does the watch stay empty after setValue?

It watches the earlier comments primitive. A later getValue from the record can return the updated field; the old variable does not become a live field binding.

Does an empty log mean the field update failed?

No. Check what the code logged. A message using an earlier copied value can be empty even when the field changed. Read the saved record to verify persistence.

Why is my script missing from Debug Existing?

Check the selected API version, assigned owner, deployed state, Testing status and permissions. Then verify Customer applicability, the mapped entry point, audience and execution context. A missing list entry alone does not identify the failed prerequisite.

Why does the debugger keep waiting?

Confirm that the action invokes the mapped entry point under the intended user, role and context. This guide makes no universal numeric timeout claim.

Does stopping the real debugger guarantee rollback?

No. The local exercise’s discard rule is not a NetSuite rollback guarantee. The debugger uses the underlying account’s data; use an authorized controlled record.

Is Coupon Code a standard Customer field or a pricing action?

No. It is a configured stored custom entity field in this example. Its ID and availability are account-specific, and assigning its text does not demonstrate a discount or coupon redemption.

Can I use these controls for SuiteScript 2.1?

No. SuiteScript 2.1 uses its 2.1 debugger and Chrome DevTools. This guide demonstrates the legacy 2.0 interface.