This article is relevant if you need to fire dependent NetSuite user events when updating other records from a User Event context.
TL;DR: Summary
Updating NetSuite records via submitFields() skips user events. Use authenticated Suitelets (for secure, synchronous updates) or async queues with Map/Reduce (for scalability) to ensure business logic fires properly.
Background
One of the recurring challenges we help NetSuite clients solve involves updating related records during business logic processing. For instance, a Sales Order may trigger an update on a related Estimate, Customer or Project record. Clients understandably expect the downstream record’s user event scripts to execute as part of this operation. Their reasons can be for auditing, business rules, or other integrations. However, developers quickly run into a limitation: when using submitFields() or record.save() within a User Event context to update another record, those target records do not fire their user events. The result? Critical business logic silently fails to execute, undermining data integrity and causing inconsistencies that are difficult to trace. This article explores techniques to overcome this shortcoming and ensure that downstream records fire their user events reliably and securely. Our colleague Boban D., Senior Technology Analyst, has been instrumental in building internal tools to support this model, and we highlight his work here.
NetSuite’s Challenge with Record Interdependencies and User Events
NetSuite’s event-driven model offers automation hooks (User Events, Client Scripts, Workflows) that allow complex business logic to be executed when a record is manipulated. However, when a record (Record A) updates another record (Record B) via submitFields() or record.save(), the target record’s user events do not execute. This limitation hampers maintainability and leads developers to implement brittle workarounds. The problem typically emerges in multi-record workflows where updates cascade across dependencies. For example, a CSV import or a user form submission that updates a Project might need to update the related Customer record. If that update doesn’t fire Record B’s logic, then key calculations, status validations, or synchronizations won’t occur.
Solution: Three Models to Fire Dependent Record User Events
Let’s go through them. In reality, there are only two options for firing dependent record user events, and one can get you into trouble.
1. Scalable Asynchronous Method (Recommended for Robust Systems)
This model queues update instructions to a custom record and later uses a Map/Reduce script to apply them, allowing user events to fire on the target record.
- Any initiator: UI, CSV import, or script triggers Record A’s User Event
- User Event writes to a queue record
- Map/Reduce script processes the queue using
record.load()+record.save() - Result: Record B updates with full event firing
Prolecto’s Utility Bundle Accelerator Template, available to all clients free-of-license-charge, makes this pattern a breeze. We have a tool that not only makes it easy to update the header of records, we can also update sublists with natural coding techniques.
2. Synchronous Suitelet Proxy with User Context (Secure, But Niche)
This method uses a special cookie in the header to call an authenticated Suitelet from a User Event script to preserve user context and fire user events synchronously. Boban D. discovered this undocumented technique and was surprised that a simple constant opens up more capacities than we understood possible for decades.
// Original (less secure) version - public Suitelet
let utilURL = url.resolveScript({
scriptId: "customscript_pri_sl_submit",
deploymentId: "customdeploy_pri_sl_submit",
returnExternalUrl: true,
params: {
tranId: context.newRecord.getValue("createdfrom"),
tranType: record.Type.SALES_ORDER,
values: JSON.stringify({ memo: "Anonymous Suitelet" })
}
});
let response = https.get({ url: utilURL });
Improved (authenticated) version with user context:
let utilURL = url.resolveScript({
scriptId: "customscript_pri_sl_submit",
deploymentId: "customdeploy_pri_sl_submit",
returnExternalUrl: false,
params: {
tranId: context.newRecord.getValue("createdfrom"),
tranType: record.Type.SALES_ORDER,
values: JSON.stringify({ memo: "User Context Preserved" })
}
});
let headers = {
cookie: "JSESSIONID=@JSESSIONID@"
};
let responseObj = https.get({ url: utilURL, headers });
Note: This method works only during live user interactions—such as form submissions or client script triggers—not during backend jobs or imports.
3. Synchronous submitFields() (Simple but Limited)
This is NetSuite’s native method to update fields on another record. It’s fast and straightforward but does not fire user events on the updated record.
if (context.newRecord.getValue("createdfrom")) {
record.submitFields({
type: record.Type.SALES_ORDER,
id: context.newRecord.getValue("createdfrom"),
values: {
memo: "Hello, World"
}
});
}
Use only when: downstream automation is unnecessary, and quick updates are acceptable. Remember the possible integrity situation that may be required for business users.
Talent: NetSuite Technical Leadership
At Prolecto Resources, we’ve used all these models and embedded the best of them in our license-free Utility Accelerator available to all clients. Whether you’re building async-safe automations or enhancing real-time workflows, we provide the logic, methods, and security structures to help you succeed.
Special thanks to Boban D., our Senior Technology Analyst, for his leadership and innovation in uncovering undocumented features and building battle-tested tools. Boban and I have a rich history that goes back to the mid-1990s. He exemplifies the technical rigor we strive to deliver in every engagement.
If you found this article relevant, feel free to sign up for notifications to new articles as I post them. If you are ready to improve the integrity and reliability of your NetSuite customizations and want to be valued for your unique insights, let’s have a conversation.
