Choosing between User Event and Client scripts in NetSuite

Decide which script type owns which behavior

1. 1If a rule must hold true no matter how the record is created (UI, CSV import, integration, workflow action), put it in a User Event script's beforeSubmit, since that is the one entry point every save path goes through.
2. 2If a rule is purely about interactive usability, such as showing/hiding a field, popping a confirmation dialog, or auto-populating a field as the user types, put it in a Client script's fieldChanged or pageInit; these never run for a CSV import or API call.
3. 3Never rely on a Client script's saveRecord function alone to block an invalid save; treat it as a first line of UX feedback and always duplicate the actual validation in a User Event beforeSubmit so non-UI paths cannot slip through.
4. 4Use beforeLoad for read-only UI adjustments that need to happen before the page renders, such as removing a button or setting a field to display-only based on role or record state.
5. 5Use beforeSubmit for validation and last-chance field manipulation before the record is committed to the database; context.newRecord and context.oldRecord are both available here for comparing changes.
6. 6Use afterSubmit for anything that needs the record's final, committed internal ID, or that triggers side effects on other records (creating a related record, calling an external API, updating a linked transaction).
7. 7In Client scripts, use postSourcing rather than fieldChanged when you need to react after NetSuite's automatic field sourcing has finished populating dependent fields, to avoid reading stale values.
8. 8Check context.type in User Event scripts (create, edit, delete, xedit, copy) and skip logic that should not apply to inline edits or mass updates if the rule only makes sense on full record saves.

beforeLoad, beforeSubmit and afterSubmit in practice

define(['N/record'], function(record) {
  function beforeSubmit(context) {
    var newRec = context.newRecord;
    var amount = newRec.getValue({ fieldId: 'total' });
    if (amount > 100000 && !newRec.getValue({ fieldId: 'custbody_vp_approved' })) {
      throw new Error('Orders over 100000 require VP approval before saving.');
    }
  }
  return { beforeSubmit: beforeSubmit };
});

Common pitfalls

• !Enforcing a required business rule only in a Client script's saveRecord, letting CSV imports and integrations bypass it entirely.
• !Reading a sourced field's value in fieldChanged before NetSuite finishes sourcing, getting a stale or empty value instead of using postSourcing.
• !Doing heavy record.load or search calls in beforeLoad on a frequently viewed list, slowing down page render for every user who opens that record type.
• !Not distinguishing context.type in a User Event script, so mass updates or inline edits trigger logic meant only for full-form saves.
• !Trying to reference the record's internal ID inside beforeSubmit on a create, when it does not exist yet; that has to wait for afterSubmit.
• !Deploying a Client script only to the form used in the UI while forgetting that other forms (or the mobile/CSV paths) for the same record type need the same protection at the User Event level anyway.