We have a UserEvent script that updates the orderstatus to Pending Fulfillment ('B') on a sales order in beforeSubmit if certain criteria is set. Its been working great for the past 2 years. All of a sudden, last week its failing on the orderstatus update. It is still setting some other fields on the SO, but orderstatus fails silently. The script executes as Admin, but it is now respecting the current users role Sales Order Approval permission. I have tested this and can confirm the result. NS support was totally useless for us here saying it is a script and our account doesn't have support for that. I have read some things that say the recent update could be the cause, and there are a few defects out already surrounding permissions. But... Will it work for our issue. We have other UserEvent scripts that look for the orderstatus update so the beforeSubmit action in the failing script is important. I figure we have 3 options here but would like to get any feedback from others who have experienced similar problems. 1. Give custom roles Sales Order Approval -> Edit permission. - I don't like this option, they don't have it currently for a reason hence the script to handle it. 2. Send the SO to a suitelet in the afterSubmit of the silently failing script. This would trigger the other UserEvent scripts to fire on orderstatus update. - I'm not sure if this would also fail to execute as Admin on the approval. 3. Do nothing & wait. Have the automation not work (manual approvals through credit dept) for now and hope NS gets whatever the issue is fixed. - I have very little faith here. Thanks for reading and any feedback would be greatly appreciated!

i think this might be a misdiagnosis but don't have the context to confirm. script does a thing, nothing changes in the script, script doesn't do a thing. something must be wrong with the script isn't a logical progression. so I'd want to confirm - were any new scripts/WFs added more recently that could be impacting this is it executing in a different context cos of a process change - used to be something that happened in the UI, now ppl are doing CSV imports to update the SOs... whatever practically speaking for the script itself, just add a ton of logging to it so you can see exactly where its getting to and what the data it's handling actually looks like when it executes what's triggering these before submits? are there changes that are now hitting via XEDIT instead of EDIT, if so the shape of the data that the script has access to can be different and so criteria that LOOK like they're met per the record aren't something the script can see.

Yes I initially thought the same thing. We have ruled out any workflows or other scripts. No business processes have changed, no settings have been updated. I have logged the orderstatus value throughout the entire script. Before the setValue - 'A', after setValue - 'B', last line of beforeSubmit - 'B', afterSubmit - 'B', database via search.lookupFields('statusRef) in afterSubmit - 'pendingApproval'

afterSubmit - 'B',

k then your beforeSubmit IS working its writing its change successfully to the database - it literally can't do ANY more than that

Correct, the script is working. Updating the roles Sales Order Approval permission from View to Edit fixes the issue (I have tested and confirmed this). I believe NS is respecting the current users permissions after the script has fully executed and is reverting the change.

Another thing I’d check is the execution order and timing of all scripts and workflows affecting the Sales Order. Since the status is

B

in

afterSubmit

but later appears as

Pending Approval

, I’d compare System Notes timestamps and the execution context/user that made the subsequent change. I’d also test the same transaction manually in Sandbox and monitor the status immediately after save and again after a short delay. That could help determine whether the status is being changed synchronously during save or by a scheduled/asynchronous process afterward.

I have the UE script in question executing last and there are no workflows on SO's that update/set orderstatus. The system notes do not display a change in orderstatus at all.

> I believe NS is respecting the current users permissions after the script has fully executed and is reverting the change. you're explaining what you're seeing in a reasonable way - but that just isn't how the NS system works, its not respecting the permissions and reverting a change, if it was respecting the permissions it wouldn't MAKE the change. its making the change your after submit confirms that... so something else after it is doing ANOTHER db write to revert the change

If the UE is executing last, there are no workflows changing the status, and System Notes show no status change, then I’d look beyond the normal script/workflow execution chain. I’d specifically investigate approval routing, native NetSuite validation, SuiteApprovals, and any asynchronous/background process that could be recalculating the status without generating the expected System Note. Reproducing it in Sandbox with execution logs and a minimal test case may help isolate whether this is a recent NetSuite platform change or a transaction-specific condition.

@Josh P Did you ever figure this out? We have a very similar script that stopped working in August after working fine for years. All it does is set the orderstatuts to 'A' for Pending Approval based on some condition. Logging shows the script executing and the condition being met, but the status does not keep.

@bbeach Yes, NS's 2026.2 update is what caused it. In the UI, SO approval requires the SO Approval permission for the user's role to be Edit or higher. NS apply's the same permission validation when SO's are approved through scripts (see screenshot). We updated our UE script to send the internal id of the SO to a suitelet to trigger the orderstatus update (which works running as admin) and it triggers any additional UE scripts that listen to that update.

@Josh P thank you! I'll look into that as an option

@bbeach No worries. Good luck.