When a script does not work as expected, execution logs are one of the first places to check. Logs can help show whether the script ran, where it failed, and what information was captured during execution.
Reading execution logs can make troubleshooting faster and help admins or developers understand what happened.
Scenario
A SuiteScript customization is not producing the expected result.
Examples may include:
- a field did not update
- an email was not sent
- a record was not created
- a script stopped before completing
- a validation message did not appear
- a scheduled process did not finish
The script may not show an obvious error to the user, so the admin needs to review the execution logs.
Solution
Open the script execution logs and review the log entries created during script execution.
Logs can show messages such as:
- audit entries
- debug details
- error messages
- record IDs being processed
- script usage details
- failed processing steps
This helps narrow down where the issue happened.
What to Check in Execution Logs
Confirm the Script Ran
First, check whether the script generated any log entries.
If there are no logs, the issue may be related to:
- script deployment status
- deployment audience
- execution role
- trigger condition
- record type mismatch
- script not being triggered
Review the Log Level
Different log levels can help identify different types of information.
Common examples:
- Debug – useful for detailed troubleshooting
- Audit – useful for key process milestones
- Error – useful for failures or exceptions
- Emergency – useful for serious script issues
If the script only logs errors, there may be limited information when no exception occurs.
Look for Error Details
Review any error log entries carefully.
Check for:
- error name
- error message
- record ID
- field ID
- line or function reference
- step where the issue occurred
This can help identify whether the problem is caused by missing data, permissions, invalid field IDs, or unexpected logic.
Compare Expected vs Actual Behavior
Use the logs to compare what the script was expected to do with what it actually did.
For example:
- Did the script find the right record?
- Did it read the expected field value?
- Did it enter the correct condition?
- Did it stop before updating the record?
- Did it process fewer records than expected?
This helps determine whether the issue is setup-related or logic-related.
Example
A script should update a custom field when a record is saved, but the field remains blank.
The execution log may show:
- the script ran successfully
- the record ID was captured
- the condition was not met
- the update step was skipped
In this case, the issue may not be the field update itself. The condition controlling the update may need review.
Sample Code
The sample below shows a simple User Event Script with different log levels.
/**
- @NApiVersion 2 .1
- @NScriptType UserEventScript
*/ define(['N/log'], (log) => {
function afterSubmit(context) {
try {
const rec = context.newRecord;
// Audit log: Confirms that the script started and identifies the record being processed.
log.audit({
title: 'Script Started',
details: `Record Type: ${rec.type}, Record ID: ${rec.id}`
});
const status = rec.getText({
fieldId: 'custrecord_request_status'
});
// Debug log: Shows the field value read by the script for troubleshooting.
log.debug({
title: 'Status Value',
details: `Status found: ${status}`
});
if (status !== 'Pending Review') {
// Audit log: Explains why the script stopped without continuing the process.
log.audit({
title: 'Condition Not Met',
details: 'Record is not Pending Review. Script will stop.'
});
return;
}
// Audit log: Confirms that the record met the condition and processing can continue.
log.audit({
title: 'Condition Met',
details: 'Record is Pending Review. Continue processing.'
});
// Add processing logic here.
} catch (error) {
// Error log: Captures failure details if the script encounters an exception.
log.error({
title: 'Script Error',
details: {
name: error.name,
message: error.message,
stack: error.stack
}
});
}
}
return {
afterSubmit
};
});
References
- SA: Using the Script Execution Log Subtab (ID:43456)
- SA: Viewing the Inspection Execution Log (ID: 106583)
Notes
- Start by confirming whether the script ran at all.
- Check deployment status and audience if no logs appear.
- Use error logs to identify failures.
- Use audit logs to confirm major processing steps.
- Avoid logging sensitive data.
- Add clearer log messages if existing logs are too vague.
- Test again in sandbox after updating logging or logic.
Summary
Execution logs are useful when a script is not working as expected. They can show whether the script ran, what steps were completed, and where errors occurred.
A good review of execution logs can help identify missing setup, incorrect conditions, permission issues, or script logic problems more quickly.
Disclaimer: The sample code described herein is provided on an "as is" basis, without warranty of any kind, to the fullest extent permitted by law. Oracle + NetSuite Inc. does not warrant or guarantee the individual success developers may have in implementing the sample code on their development platforms or in using their own Web server configurations.
Oracle + NetSuite Inc. does not warrant, guarantee or make any representations regarding the use, results of use, accuracy, timeliness or completeness of any data or information relating to the sample code. Oracle + NetSuite Inc. disclaims all warranties, express or implied, and in particular, disclaims all warranties of merchantability, fitness for a particular purpose, and warranties related to the code, or any service or software related thereto.
Oracle + NetSuite Inc. shall not be liable for any direct, indirect or consequential damages or costs of any type arising out of any action taken by you or others related to the sample code.
Share your insights and experiences in the NetSuite Admin Corner.
