When a script is deployed on a record type, it may run for more users, forms, or scenarios than originally intended. If the script should only apply to one custom form, the deployment scope and script logic should be planned carefully.
Planning the scope helps prevent unexpected updates, unnecessary errors, and user disruption.
Scenario
A business team has more than one custom form for the same record type.
Example:
- Standard Request Form
- Finance Review Form
- Operations Review Form
A script should run only when users work with the Finance Review Form.
If the script runs on all forms, it may update records incorrectly or apply logic to users who should not be affected.
Solution
Deploy the script on the correct record type, then add logic to confirm the form before the script continues.
The script should check the current form or form-related value and exit if the record is not using the intended form.
This helps keep the script behavior limited to the correct business process.
Why Deployment Scope Matters
A script that runs too broadly can cause issues such as:
- changing records that should not be changed
- showing validation messages on the wrong form
- creating errors for unrelated users
- slowing down record entry
- making troubleshooting harder
Even if the script is deployed correctly, it is still a good practice to include script logic that confirms whether the current form is the intended one.
What to Check Before Building the Script
Before writing the script, confirm:
- which record type the script should run on
- which custom form should trigger the logic
- whether the script should run on create, edit, or both
- which roles use the form
- whether the same record can be edited later from a different form
- whether the script should stop or skip processing when the form does not match
This helps avoid running logic in the wrong context.
Sample Script Logic
The sample below shows a simple User Event Script that checks the custom form before continuing.
Replace the form internal ID and field IDs with the actual values from your account before testing.
/**
* @NApiVersion 2 .1
* @NScriptType UserEventScript
*/
define(['N/log'], (log) => {
const TARGET_FORM_ID = '123'; // Replace with the internal ID of the target custom form
function beforeSubmit(context) {
const rec = context.newRecord;
const currentForm = rec.getValue({
fieldId: 'customform'
});
if (String(currentForm) !== TARGET_FORM_ID) {
log.audit({
title: 'Script Skipped',
details: `Record is not using target form. Current form: ${currentForm}`
});
return;
}
// Add form-specific logic here.
log.audit({
title: 'Target Form Confirmed',
details: 'Script logic will continue.'
});
}
return {
beforeSubmit
};
});
How It Works
- The script reads the customform field.
- It compares the current form to the target custom form ID.
- If the form does not match, the script stops by using return.
- If the form matches, the script continues with the intended logic.
Notes
- Deploy the script on the correct record type.
- Confirm the internal ID of the target custom form.
- Test using all forms assigned to the record type.
- Test with the roles that will use the form.
- Consider whether records may be edited later using a different form.
- Add clear log messages so skipped executions are easy to understand.
- Avoid relying only on form layout if the business rule should apply more broadly.
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.