The quick answer
Go to Customization > Scripting > Scripted Records and click View on the record type, here Sales Order. The Scripted Record page lists everything attached to that record type on subtabs: User Event Scripts, Client Scripts, Custom Forms and Workflows. If a field changes when the record is saved, start with the user event script that has a Before Submit Function. It runs on the server just before the record is written, so a value it sets is saved with the record. Click the script name to open its Script record, read the Description, and check on the Deployments subtab that it applies to Sales Order, is Deployed and has Status Released. Then confirm it with the order's System Notes and the script's Execution Log.
The screenshots show sample data. The company, people and scripts are fictional. Your account will list its own record types, scripts and workflows.
Before you start
You need the Administrator role, or a role with the customization and SuiteScript permissions to see the Customization > Scripting pages. Server SuiteScript has to be enabled for scripts to run, and the Workflows subtab only matters if SuiteFlow is on. Nothing in this guide changes a script or deployment. Use View on Scripted Records, not Edit. Edit lets you reorder scripts and change deployment status on the record type.
In this example, sales reps at Larkspur Ridge Supply Co. report that the Department on their sales orders changes when they click Save. Noor Haddad, the administrator, wants to find out which customization does it. She doesn't know the script's name, and the Scripts list doesn't help much without one.
01. Open Scripted Records
Go to Customization > Scripting > Scripted Records. It sits in the same menu as Scripts and Script Deployments.
Scripted Records has one row per record type that has scripts deployed, with Edit | View links, Record, Script ID, Scripts and Workflows. The Scripts and Workflows columns count what's attached. Here the Sales Order row, Script ID salesorder, shows 3 scripts and 1 workflow.
Show Undeployed is unchecked here, so the list only shows record types with deployed scripts. Check it to include record types that have none. The Script filter at the top narrows the list to the record types a chosen script is associated with.
02. Read the user event scripts on Sales Order
Click View on the Sales Order row. The Scripted Record page shows Name Sales Order and ID salesorder, with subtabs for User Event Scripts, Client Scripts, Custom Forms, Workflows, Localized User Event Scripts and Localized Client Scripts. A dot after a subtab name means it has rows.
The User Event Scripts subtab lists each script with its Owner, API Version, bundle columns, Status and three function columns. Those columns name the entry points each script runs. They don't tell you what the code does.
Two scripts are listed:
- SO Credit Hold Check UE has beforeLoad and afterSubmit. beforeLoad runs when the record is loaded, for example when someone opens or creates an order. afterSubmit runs after the order is committed, so to change a field it would have to update the order again in a separate save.
- SO Department Defaults UE has only beforeSubmit. It runs on the server just before the order is written. In the UI that's right after the user clicks Save. A value it sets is saved with the order.
That makes SO Department Defaults UE the first suspect for a field that changes on save.
03. Check the client script and the workflow
Don't stop at the user event scripts. Client scripts and workflows can set fields too.
Click the Client Scripts subtab. SO Line Validation CS has only a Validate Line Function, validateLine. It runs in the browser as each item line is added, so it's an unlikely source of a header field that changes on Save. If nothing else fits, read its code anyway.
A client script with a Save Record or Field Changed function would deserve a closer look. Client scripts only run in the browser while someone works in the form, though, not when an order is saved by a CSV import, web services or a server-side script. User event scripts and workflows can run for those, and for a CSV import that depends on its Run Server SuiteScript and trigger WorkFlows option.
Click the Workflows subtab. Sales Order Approval Routing is Released, and its description says it routes orders over the customer's credit limit to the sales manager for approval. Nothing about Department.
A description is only what someone typed. A workflow can change fields with a Set Field Value action, like the one in how to show who entered a sales order with a workflow, so check its initiation settings, states and actions before you rule it out completely. The walkthrough doesn't open the Custom Forms subtab. It lists forms on the record type and the client script attached to each, so check it too if your forms have scripts.
04. Open the suspect script
Go back to the User Event Scripts subtab and click SO Department Defaults UE. The script name opens the Script record, not the deployment.
The Script record shows Type User Event, ID customscript_so_department_defaults and Owner Devon Achterberg. The Description says it sets Department from the sales rep's department before the order is saved. On the Scripts subtab, the script file is so_department_defaults_ue.js and only Before Submit Function is checked.
Descriptions are often blank or out of date. If yours is, the script file is the next place to look.
05. Confirm the deployment is live
Click the Deployments subtab. The deployment customdeploy_so_department_defaults applies to Sales Order, Deployed is Yes and Status is Released. Event Type is blank, so the deployment adds no event-type limit. The script still runs only the entry points it implements, here beforeSubmit.
Check the result (example values)
- Scripted Records shows Sales Order with 3 scripts and 1 workflow.
- SO Department Defaults UE is the only user event script with a Before Submit Function.
- The client script runs only validateLine, and the workflow's description is about credit-limit approval.
- The Script record's Description says it sets Department before the order is saved.
- Its deployment applies to Sales Order, is Deployed and is Released.
Released means it runs for the deployment's audience. Testing generally runs only for the script owner, which can explain why a change happens for one person and not others. The deployment's audience and execution context settings can narrow it further, so check those if the change only happens for some users or some kinds of save.
This is a strong suspect, not proof. Take the script to its owner, and confirm it two ways: the order's System Notes show when Department changed and in what context, and the deployment's Execution Log can show whether it ran when you reproduce the save. With Log Level Error, as here, a successful run may log nothing unless the script writes its own message at that level. Department can also come from field sourcing, a form default, another workflow, an import or an integration.
You can find the same scripts and workflows through Customization > Scripting > Scripts, Script Deployments or Customization > Workflow > Workflows. Those lists are organized by script or workflow, so they work when you already know or can guess the name. Scripted Records starts from the record type, which is what you know when a field misbehaves. If you want to stop a save rather than find what changes it, see how to block a purchase order save with a workflow error.
Common questions
Where is Scripted Records, and who can see it?
It's under Customization > Scripting > Scripted Records, in the same menu as Scripts and Script Deployments. Administrators see it. Other roles need customization and SuiteScript permissions, so if the menu item isn't there for you, ask an administrator to check your role.
What's the difference between beforeLoad, beforeSubmit and afterSubmit?
beforeLoad runs when a record is loaded, before the user sees the form. beforeSubmit runs after Save is clicked and before the record is written, so it can change a field that's saved with the record. afterSubmit runs after the save and is usually for follow-up work, such as updating another record or sending data somewhere. When a field changes on save, beforeSubmit is the first place to look.
Can I change the order scripts run on a record?
Yes. Edit on the Scripted Records row lets an administrator reorder the scripts on that record type. This guide only uses View, and nothing is reordered. If two scripts set the same field, the order decides which value wins, so test a change in a sandbox before you make it in production.
How do I tell if a script deployment is Released or Testing?
The Status column on the User Event Scripts and Client Scripts subtabs shows it, and so does the Deployments subtab on the Script record. Released runs for the deployment's audience. Testing generally runs only for the script owner. Check Deployed too, because a deployment that isn't deployed doesn't run whatever its status says.
How do I stop a suspect script for a while without deleting it?
Open its script deployment and clear Deployed, then save. The script and its settings stay in place, and you can deploy it again later. That changes live behavior for everyone, so agree on it with the script's owner and try it in a sandbox first if you can.
What if nothing on Scripted Records looks responsible?
Look past the attached scripts. Check the order's System Notes to see when the field changed and in what context, then field sourcing, form defaults, custom forms with their own client scripts, CSV imports and integrations. A client script with only validateLine is an unlikely cause, but read its code if nothing else fits.