Native-Record Footprint Map

01Executive Summary

Every one of the six core record types is being reshaped by three or more distinct providers — the flag threshold for this audit was met account-wide, 6 for 6. Transactions carry the heaviest load: Sales Order and Invoice are each touched by 10 distinct providers. Three providers dominate everywhere: Electronic Bank Payments, SuiteTax, and Atlas/SuiteSuccess.

Counts include only verified attachments. Three Sonar VBM fields on Vendor Bill are listed in the explorer but excluded from counts (attachment metadata empty, zero populated rows — see Assumptions #7).

02Provider × Record-Type Matrix

Each cell is the number of verified custom fields that provider attaches to that record type. Color intensity scales with count. This is the single best view of who is reshaping what.

03Per-Record Composition

Share of each record type's custom-field footprint by provider. Bar width is proportional to field count.

04Field Explorer (interactive — search, filter; 258 rows)

The complete inventory. Every field is cited by its actual NetSuite scriptid. Filter by record type, provider, or free text. Badges: live-verified = confirmed by querying real data, unverified = attachment inferred but not confirmed, risk = flagged security concern.

05Key Findings

1. F1 — Universal flag condition. All six core record types exceed the 3-provider threshold. The account has no "clean" core record: even Vendor, the lightest at 20 fields, carries 6 providers. Any form redesign, integration mapping, or CSV import template for these records must account for multi-provider field ownership.
2. F2 — EBP is the most invasive provider. Its EFT/direct-debit columns (custcol_9572_*, custcol_2663_*, custcol_9997_dd_file_format) attach to sales-side line items on Sales Orders and Invoices — 11 line columns on SO that have nothing to do with order entry. This is pure form noise for sales users and a common source of "why is this field here?" confusion.
3. F3 — Atlas write-attribution fields blanket everything. custbody_atlas_source/_source_actor/_request_id/_justification/_committed_at appear on ~28 transaction types each. They are the Atlas agent-write audit layer — harmless but they inflate every transaction form's field count by 5+.
4. F4 — Test debris is half the Customer footprint. 22 TDM-tooling fields on Customer, 1 on Vendor, 2 TDM body fields on SO/Invoice, plus 5 WS-configurator demo fields on Item: 28 fields with no business owner. All are retirement candidates.
5. F5 — Local (genuinely in-house) footprint is small and coherent. PromoStandards app (7 fields across Vendor + Item), matrix attributes on Item (Color/Size/Mattress/Image Code), custbody_inhand_date, custentity_renewal_risk, Sonar VBM (4 fields), RAC case-linking (2). The reshaping pressure is overwhelmingly from bundles, not local customization.
6. F6 — Credential exposure. custentity_ps_password remains a plain-text password on vendor records, readable by any role with vendor access. (Repeat flag from 2026-08-05.)
7. F7 — Attribution gaps exist but are minor. 8 fields could not be conclusively attributed (e.g. custentity_naw_trans_need_approval, custitem_cust_uom, the supply-alert trio, custcol_ns_usetax). None appear high-risk; all are catalogued under "Unknown / unattributed" pending an owner interview.

06Recommendations

07Methodology & Data Sources

All data was gathered live from account TD3016323 on 2026-08-22 via SuiteQL and SuiteScript record introspection. No cached or training-data field lists were used.

Pipeline

1. Schema discovery. A one-row SELECT * FROM customfield established the columns actually exposed in this account (notably fieldtype and visibleontransactions; there is no applies-to column, and per-type tables like transactionbodycustomfield do not exist here).
2. Entity fields (Customer / Vendor). recordTypeDescribe output truncated for both types, so a read-only research subagent verified attachment by live column presence on SELECT * FROM customer / vendor, cross-checked with per-field fieldDescribe probes for field types that don't surface as SQL columns (long text, inline HTML, hidden). Negative tests confirmed non-attachment (e.g. custentity_ste_vendor_stecode is NOT on customer).
3. Transaction fields (SO / Invoice / Vendor Bill). Authority = customfield.visibleontransactions, the comma-delimited list of NS transaction short codes each BODY/COLUMN field applies to. Retrieved for all 141 body+column fields via keyset pagination (LIKE filters on this column are rejected — it is computed; see Assumptions #3).
4. Item fields. All 36 fieldtype='ITEM' rows, with attachment corroborated by a subagent describe of inventoryitem (the dominant item type: 263 of 374 items).
5. Provider attribution. Scriptid-prefix heuristic (see Assumptions #1), consistent with the account's known bundle inventory. customsegment.frombundle is empty for ALL rows in this account, so prefix attribution is the only viable method.
6. Spot verification. Fields with ambiguous metadata were checked against real transaction data — e.g. custcol1 (Color) has an empty applies-to list yet is populated on 103 live Sales Order lines; the Sonar VBM flag has zero populated Vendor Bills.

Verification levels used in this report

• Verified — attachment confirmed by live SQL column presence, fieldDescribe, or explicit visibleontransactions membership. 255 of 258 rows.
• Live-verified — additionally confirmed by real stored data (e.g. custcol1).
• Unverified — plausible but unconfirmed (3 Sonar VBM fields on Vendor Bill); excluded from all counts.

08Source Queries

Reproduce this audit by re-running these against the account. Q2/Q3 are paged by scriptid keyset because result size exceeds a single response window.

SELECT * FROM customfield WHERE fieldtype = 'ENTITY' FETCH FIRST 1 ROWS ONLY

SELECT scriptid, name, fieldtype, visibleontransactions
FROM customfield
WHERE fieldtype IN ('BODY','COLUMN') AND visibleontransactions IS NOT NULL
ORDER BY fieldtype, scriptid
-- 141 rows total; paged with maxRows + scriptid keyset, e.g. page 2:
--   AND ((fieldtype='BODY' AND scriptid > 'CUSTBODY_MFGMOB_WOBACKFLUSH') OR fieldtype='COLUMN')

SELECT scriptid, name, visibleontransactions
FROM customfield
WHERE fieldtype = 'COLUMN' AND visibleontransactions IS NOT NULL
  AND scriptid > 'CUSTCOL_2663_LASTNAME' AND scriptid < 'CUSTCOL_SCM'
ORDER BY scriptid

SELECT scriptid, name FROM customfield WHERE fieldtype = 'ITEM' ORDER BY scriptid
-- 36 rows

-- Attachment authority = live column presence:
SELECT * FROM customer FETCH FIRST 1 ROWS ONLY   -- keys inspected, not values
SELECT * FROM vendor   FETCH FIRST 1 ROWS ONLY
-- Labels recovered from (63 ENTITY fields account-wide):
SELECT scriptid, name FROM customfield WHERE fieldtype = 'ENTITY' ORDER BY scriptid
-- Non-SQL-surfacing field types (longtext/inlinehtml/hidden) probed via fieldDescribe(recordType, fieldId)

SELECT
  SUM(CASE WHEN t.type = 'SalesOrd' AND tl.custcol1 IS NOT NULL THEN 1 ELSE 0 END) AS so_color_lines,   -- → 103
  SUM(CASE WHEN t.type = 'VendBill' AND t.custbody_sonar_vbm_flag IS NOT NULL THEN 1 ELSE 0 END) AS vb_vbm_flagged  -- → 0
FROM transaction t JOIN transactionline tl ON tl.transaction = t.id
WHERE t.type IN ('SalesOrd','VendBill')

09Assumptions, Caveats & Known Limitations

1. Provider attribution is a scriptid-prefix heuristic. customsegment.frombundle and equivalent bundle-linkage metadata are empty account-wide, so ownership is inferred from naming conventions (_ATLAS_, _2663_/_9572_/_9997_/_15529_ = EBP numbered-bundle family, _STE_/_STR_, _PACKSHIP_/SHIPCENTRAL, _SCM_, _FAM_/_FAR_/_NCFAR_, _MFGMOB_, _WS_, TDM/TK, etc.). This matches the account's known installed-bundle inventory but is not authoritative bundle metadata.
2. _C360_ → Cash 360 and _11724_ → EBP-family are probable, not certain — numbered-prefix style matches, but neither prefix was cross-confirmed against a bundle manifest. Marked as such in the explorer.
3. visibleontransactions is the attachment authority for transaction fields. Strictly it encodes visibility/applies-to as configured; a field could exist but be hidden on a given custom form. Also note: SQL LIKE filters against this column silently return 0 rows (it is a computed multivalue) — filtering was therefore done client-side after full retrieval.
4. Item = inventoryitem as representative. Item custom fields can be scoped to subsets of item types; per-subtype applies-to was not decomposed. All 36 ITEM fields are shown; a small number may not render on e.g. Service or Kit forms.
5. custcol1 (Color) has empty applies-to metadata but is live-verified on 103 SO lines. It very likely flows to Invoices via transform, but no populated invoice line was verified — it is counted on SO only.
6. FAM's footprint on core records is nearly nil by design — its 40+ body fields target custom transaction types (Custom101–105: lease/depreciation journals), not the audited six. Only custcol_far_trn_relatedasset touches SO/Invoice/Vendor Bill.
7. Sonar VBM body fields (custbody_sonar_vbm_flag/_reason/_detail) have empty applies-to metadata and zero populated Vendor Bills. They are listed as unverified and excluded from all counts; Vendor Bill's provider count is stated as 7 verified (8 if Sonar confirmed).
8. Segments were counted only where directly observed (cseg_client_tag on Customer). The Atlas segments (cseg_atlas_cost_ctr, cseg_atlas_sls_chan) and Merch Hierarchy segments apply at the transaction/line level per prior sessions but were not re-verified in this sweep, so they are excluded from counts — a conservative choice that slightly understates Atlas's transaction footprint.
9. Point-in-time snapshot. Accurate as of 2026-08-22. Bundle updates routinely add/remove fields; re-run Q1–Q6 to refresh.