Finding the scripts that slow every save

The business side is in your ERP isn’t slow. This is how to find out what’s actually running.

1. What’s deployed on the record

SELECT sd.recordtype, s.scripttype, s.name, sd.status, sd.loglevel
FROM scriptdeployment sd
JOIN script s ON s.id = sd.script
WHERE sd.isdeployed = 'T'
  AND UPPER(sd.recordtype) IN ('SALESORDER','ESTIMATE','CUSTOMER','CONTACT')
ORDER BY sd.recordtype, s.scripttype

The count alone is informative. Dozens of user events on one record type is common in accounts that have been customized for years, and each one runs on every save. Note the owner of each script too: your own, a consultant’s, or a vendor bundle’s.

2. Who’s writing to the log

SELECT s.name, sn.type, COUNT(*) AS rows_written
FROM scriptnote sn
JOIN script s ON s.id = sn.scripttype
WHERE sn.date >= SYSDATE - 7
GROUP BY s.name, sn.type
ORDER BY rows_written DESC

Scripts left at DEBUG after development are the usual offenders. A handful of them on a busy record can write over a million rows a week, and every log.debug call is work done during the save. Production deployments on high-volume records should log at ERROR unless someone is actively investigating.

3. Who’s failing

The same query filtered to sn.type = 'ERROR' finds scripts failing quietly on every save. Tens of thousands of errors a week from one script is a defect, and each failure still costs time before it fails.

Changing log levels safely

Log level is a deployment setting, not code, so changing it doesn’t require a deploy. It’s still a production change: list the deployments you intend to change, change them, then re-run query 1 to confirm every one reads ERROR. Leave anything you’re actively debugging at its current level and note why.

The trap: a failing script isn’t necessarily a useless one

The noisiest script in one review was a payment-gateway script failing tens of thousands of times a week. The obvious recommendation was to undeploy it. The finance lead asked a better question: did it ever work?

Reading the code showed two branches. One was genuinely broken, failing on a bad search filter. The other was succeeding quietly, updating the authorization records a reauthorization process depends on. Undeploying it would have stopped the errors and broken payments. The right fix was the broken branch alone.

Removing dead scripts

For features nobody uses, confirm with the business, then search for references before undeploying. We search saved search definitions and the code repository for every custom field the script owns. Only when both come back clean does it go, and the deployment is kept, set to not deployed, rather than deleted — so it can be restored in a minute if something was missed.

Measure before and after

Use the platform’s performance monitoring to record median and 95th-percentile save times for the record before changes, then again a week after. Without a baseline, “it feels faster” is the only result anyone can report.

Related: your ERP isn’t slow, and reading a NetSuite stack trace.