RCRD_HAS_BEEN_CHANGED — what it means and how to fix it

When you see this

• Two users edit the same record and the second to save is blocked with RCRD_HAS_BEEN_CHANGED.
• A script loads a record, does slow work, then submits - and a workflow or another script changed it in between.
• An integration sends concurrent updates to the same record and some fail with this error.

Causes

• Optimistic locking: NetSuite stamps a record version on load and rejects a save if the stored version moved on - someone or something saved it first.
• Long-running edits: a record loaded, held open or processed slowly, is changed by a user, workflow or scheduled script before submit.
• Concurrent API or integration updates to the same record without serialisation or retry.

Fix

Reload the latest record, re-apply your change to that version, and serialise or retry concurrent updates so they do not collide.

1. In the UI, refresh the record to load the current version, re-enter your change and save again.
2. In SuiteScript, prefer record.submitFields for targeted field updates, and keep load-modify-submit as close together as possible to shrink the window.
3. Add a bounded retry-on-RCRD_HAS_BEEN_CHANGED loop (reload, re-apply, resubmit) for updates that can legitimately race.
4. Serialise updates to hot records - queue them, or use a single Map/Reduce reduce stage per key - so two processes do not write the same record at once.

Prevent it

• Keep load-modify-submit tight; avoid holding records open across slow work.
• Use submitFields for single-field updates instead of a full load and save.
• Serialise or queue concurrent writes to the same record; add bounded retries.

SuiteScript version note: The optimistic-locking behaviour applies across SuiteScript 2.x, SuiteTalk and the UI. record.submitFields (2.x) is the lightweight update that most reduces the collision window.

Frequently asked questions

Why do I get RCRD_HAS_BEEN_CHANGED when I am the only user?

A background process likely changed the record - a workflow, a scheduled or user-event script, or an integration - between your load and save. Refresh to the current version and retry; if a script races yours, tighten or serialise the updates.

How do I avoid this in a SuiteScript?

Minimise the time between load and submit, use record.submitFields for single-field changes, and wrap racing updates in a bounded reload-and-retry. For high-contention records, serialise writes through a queue or a Map/Reduce reduce stage keyed on the record.

Does NetSuite lock records to prevent this?

NetSuite uses optimistic locking, not a hard lock: it lets you load freely but rejects a save if the record changed since load. That avoids long-held locks but means your code must reload and retry when a collision happens.