Script-Stacking Analysis — Core Transactions

01Executive Summary

All three core transaction types are flagged: Sales Order carries 6 active user-event scripts, Invoice 7, Vendor Bill 6 — every one past the 3-script threshold. Between five and six independent provider families fire on each record. Three "monolith" script pairs (USR, STE, LRC — one UE + one client script each) deploy across all three record types, so a regression in any of them hits the entire order-to-cash and procure-to-pay surface at once.

02Stack Matrix

Active script counts per record type, split by script type, with the effective save-path depth (event-scoped scripts removed) and distinct provider families. Computed from the deployment array at render time.

† Active UE scripts that fire on create/edit saves — excludes the DELETE-scoped NAW deployment. Every UE script here declares no event-type restriction unless badged.

03Execution Stacks by Record Type

Each card lists the full stack — user-event lane, then client lane. Rows are ordered by script internal id (creation order — a weak proxy only; see §04). Disabled deployments are dimmed: they don't fire today, but one checkbox re-arms them.

04Execution Ordering — What Is and Isn't Knowable

• The authority is the Scripted Records page — Customization > Scripting > Scripted Records > [record type]. Same-event UE scripts execute top-to-bottom as listed there; the page supports manual reordering. That sequence lives in no SuiteQL-exposed table: scriptedrecord returns "Invalid search type" in this account.
• Trap documented: scriptdeployment.id looks like an ordering key but is a per-script sequence number (multiple rows share id 1) — the globally unique key is primarykey, and neither encodes execution order. Do not sort stacks by either and call it execution order.
• What this report uses instead: script internal id (creation order) as a stable, honest listing order — labeled as such, never as execution order.
• Within one save, lanes are deterministic: client validation → beforeLoad (on next render) / beforeSubmit (all scripts, Scripted-Records order) → commit → afterSubmit (all scripts, same order). The stacking risk concentrates in beforeSubmit/afterSubmit, where six-plus scripts share one record instance and one governance budget.

05Key Findings

1. F1 — All three record types exceed the UE threshold (FLAGGED). Active user-event scripts: Sales Order 6, Invoice 7, Vendor Bill 6 against a threshold of 3. Save-path depth after event-scoping: 6 / 6 / 5. Every save of a core transaction runs a five-to-six-script gauntlet before it commits.
2. F2 — Three monolith families ride every core transaction (OPERATIONAL). USR (customscript_usr_ue_transaction + _cs_), STE (customscript_ste_ue_transaction + _cs_), and LRC Field Manager (customscript_lrc_field_manager_ue + _cs) are single scripts with per-record deployments on all three types. Single point of failure across the transactional core; STE is at least a known bundle (SuiteTax) — USR and LRC are not confirmed.
3. F3 — Attribution gap on the hot path (OPERATIONAL). USR, LRC, and NAW families have no confirmed provider. script.owner is no help — it records the installing user (Kathryn Glass for 17 of 20 scripts, Ryan Rote for the SCM trio), not the vendor. Three unattributed script families executing on every core-transaction event is a governance hole: nobody can say what they do, who patches them, or whether they can be retired. (NAW also owns the unattributed custentity_naw_trans_need_approval field from the Footprint Map.)
4. F4 — The EBP generation pair repeats in script form (COSMETIC). "Generic Payment Information Hider" exists as SS1 (customscript_2663_payment_info_ue — deployments present but disabled on Invoice + Vendor Bill) and SS2 (customscript_15486_payment_info_ue — active on both). Exactly the pattern of the DD-file-format field duplicate from the Concept Sweep: two bundle generations, one concept. The SS1 deployments are latent re-enable hazards.
5. F5 — Event scoping is underused (OBSERVATION). Only 1 of 23 UE deployments declares an event-type restriction (NAW → DELETE). Every other script fires on every event and self-filters in code — invisible to this analysis and to any admin reading the deployment list. Scoped deployments would make the true stack legible.
6. F6 — Sales Order is the most contested record in the account (SYNTHESIS). Combining volumes: 10 field providers (Footprint Map), the color/size silo lives on its lines (Concept Sweep), and now 7 provider families' scripts (6 UE + 7 client active). Any SO form or workflow change needs multi-party impact review.
7. F7 — Error-rate evidence unavailable this session (LIMITATION). Every scriptnote query — including shapes previously verified in this account — returned "An unexpected SuiteScript error". Whether the stacked scripts are actually erroring is unknown from this run; the script-telemetry-review process (or the scripting tool group's log reader) is the follow-up path. The account field notes claiming scriptnote is queryable need a recheck.

06Recommendations

07Methodology

1. Schema probe first. SELECT * FROM scriptdeployment FETCH FIRST 1 ROWS ONLY established the exposed columns: recordtype (plain uppercase names), status, isdeployed, eventtype, executioncontext, and the id-vs-primarykey split.
2. Record-type encoding survey. A GROUP BY over UE/client deployments confirmed the encoding (SALESORDER, INVOICE, VENDORBILL) and gave account-wide stack counts for context.
3. Main pull. All UE + client deployments for the three types, joined to script (type, inactive flag, owner) and file (source filename). 38 rows. A first attempt included executioncontext — dropped on re-query because every deployment carries the full ~35-context list, bloating output with zero signal.
4. Active = status='RELEASED' AND isdeployed='T' AND script not inactive. All 38 rows are RELEASED and no script is inactive, so the discriminator here is isdeployed (34 T / 4 F).
5. Provider attribution by scriptid prefix against the account's known bundle inventory (same registry as the Footprint Map): ste_ SuiteTax, scm_ SCM bundle, 2663_/15486_ EBP generations, packship_ Ship Central, rac_/atb_ local-uncertain, usr_/lrc_/naw_ unattributed. script.owner was pulled and rejected as an attribution source (it's the installing user).
6. Ordering honesty. scriptedrecord probed and found not SQL-exposed; the scriptdeployment.id per-script-sequence trap verified (multiple rows share id=1) and documented; listing order fell back to script internal id, labeled as creation order.
7. Error-log attempt. Three scriptnote query shapes (grouped, filtered, plain recent-rows) all returned "An unexpected SuiteScript error" — recorded as F7 rather than silently omitted.

08Source Queries

SELECT * FROM scriptdeployment FETCH FIRST 1 ROWS ONLY

SELECT sd.recordtype, s.scripttype, COUNT(*) AS n
FROM scriptdeployment sd JOIN script s ON s.id = sd.script
WHERE s.scripttype IN ('USEREVENT','CLIENT')
GROUP BY sd.recordtype, s.scripttype ORDER BY COUNT(*) DESC
-- recordtype = plain uppercase names (SALESORDER, INVOICE, VENDORBILL)

SELECT sd.recordtype, s.scripttype, s.name AS script_name, s.scriptid AS script_sid,
 sd.scriptid AS deploy_sid, sd.status, sd.isdeployed, sd.eventtype, s.isinactive, f.name AS filename
FROM scriptdeployment sd
JOIN script s ON s.id = sd.script
LEFT JOIN file f ON f.id = s.scriptfile
WHERE sd.recordtype IN ('SALESORDER','INVOICE','VENDORBILL')
 AND s.scripttype IN ('USEREVENT','CLIENT')
ORDER BY sd.recordtype, s.scripttype, s.name
-- → 38 rows; active = isdeployed='T' (all RELEASED, no inactive scripts)

-- scriptdeployment.id is PER-SCRIPT sequence, not global (many rows share id=1):
SELECT sd.id, sd.recordtype, sd.scriptid FROM scriptdeployment sd
JOIN script s ON s.id = sd.script
WHERE sd.recordtype = 'SALESORDER' AND s.scripttype = 'USEREVENT'
-- global unique key = primarykey; NEITHER encodes execution order.
-- Execution order lives on the Scripted Records page only:
--   scriptedrecord → "Invalid search type" (not SQL-exposed)

SELECT s.id, s.scriptid, s.name, s.owner, e.entityid AS owner_name
FROM script s LEFT JOIN employee e ON e.id = s.owner
WHERE s.scriptid IN ('...the 20 scripts...') ORDER BY s.id
-- → owner = installing user (17× one admin, 3× another), NOT the vendor.
-- Attribution must come from scriptid prefixes + bundle records.

SELECT s.scriptid, COUNT(*) FROM scriptnote sn JOIN script s ON s.id = sn.script
WHERE sn.type = 'ERROR' AND s.scriptid IN (...) GROUP BY s.scriptid
-- → "An unexpected SuiteScript error" on this and two simpler shapes.
-- Follow-up path: script-telemetry-review process / scripting tool group.

09Assumptions, Caveats & Limitations

1. Scope = script deployments with recordtype exactly matching the three types. Scripts touching these records indirectly (scheduled/MR scripts loading SOs, workflows, Suitelets transforming records) are out of scope — this is the event-time stack only. Workflows in particular can add save-time logic and were not enumerated.
2. Execution order is NOT claimed. Listing order is script creation order; the Scripted Records page is the only authority (§04).
3. Provider attribution is the prefix heuristic (same limits as the Footprint Map): USR/LRC/NAW honestly unattributed; RAC/ATB local-uncertain; script.owner rejected as evidence.
4. "Active" means deployable metadata state (RELEASED + isdeployed + script active). A script can be metadata-active and behaviorally dormant (self-filtering to nothing) — source-level review was out of scope.
5. Event-scope credit given only to declared eventtype restrictions. Scripts that self-filter in code still count in the save-path stack — from the platform's perspective they load and execute.
6. Client-script stacking is form-mediated: which client scripts actually attach can vary by custom form; the deployment-level view is the upper bound per record type.
7. Error-rate evidence unavailable this session (scriptnote errors — F7); stacking risk is assessed structurally, not from failure telemetry.
8. Point-in-time snapshot (2026-08-22). Bundle updates add/remove deployments; re-run Q2/Q3 to refresh. Threshold (>3 active UE) is the requested flag line, not a NetSuite limit.