deletedrecord
transactionThe deletion ledger: one row per deleted record with its type, name, script id, who deleted it and when. The only public evidence that something disappeared.
this ledger records deleted RECORDS, not deleted LINES — a line removed from a surviving transaction never appears here, so line tables need a periodic full refresh; see quirks #deletes.
The Help Center discusses this surface as "deletedRecordInConnect" and the legacy Connect schema names the table deleted_records; in the 2021.1 analytics catalog the one and only record is deletedrecord. Diffing it against your landed copy is how a lastmodifieddate watermark stops silently keeping dead rows alive.
What the badges mean
- master
- Data class: what the record holds — master data, transaction documents, control/configuration, or a documented convenience record. NetSuite has no product-family or schema axis, so this is the whole classification.
- Subsidiary-scoped
- The record carries a
subsidiarycolumn that partitions its rows, so the generated SQL anchors it. On a few records the column is a multiselect rather than a scalar foreign key — the table notes say which (see the quirks guide). - Location-scoped
- The record carries a
locationcolumn — an org segment in NetSuite before it is a warehouse — and the generated SQL anchors it the same way. - View
- A documented convenience record rather than a stored one. Land the records it stands in for instead of assuming it extracts as-is — the table notes say where the rows actually live.
Structural facts — how the record is partitioned, not a trap by itself
Join & extract hazards — verify before you rely on this
'T'/'F' string.Fields
10 fields
10 fields.
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | recordtypeid | Record type deleted, as text | VARCHAR | |
| 2 | type | Type of the deleted record, as text | VARCHAR | |
| 3 | name | Name of the deleted record | VARCHAR | |
| 4 | scriptid | Script id of the deleted record | VARCHAR | |
| 5 | deleteddate | When the record was deleted | TIMESTAMP | The record's primary analysis date — a real DATE/TIMESTAMP column, no conversion needed |
| 6 | deletedby | Who deleted it (internal id) | NUMBER | |
| 7 | context | Context the deletion came from (internal id) | NUMBER | |
| 8 | iscustomrecord | Deleted record was a custom record | VARCHAR | |
| 9 | iscustomlist | Deleted record was a custom list | VARCHAR | |
| 10 | iscustomtransaction | Deleted record was a custom transaction | VARCHAR |
Field provenance: hand-curated.
Boilerplate SQL
Starting point for reading the Connect-landed copy of deletedrecord on Databricks — dates are real DATE/TIMESTAMP columns and need no conversion, and the partition anchors are already in place. This record carries no modification stamp, and the snippet says so where the watermark would otherwise go. Set your Unity Catalog location, schema, and filter values below; they’re substituted into the SQL and the copy button.
4 parameters not filled: <catalog>, <schema>, <DATE_FROM>, <DATE_TO>
-- ============================================================
-- Table : deletedrecord — The deletion ledger: one row per deleted record with its type, name, script id, who deleted it and when. The only public evidence that something disappeared.
-- Purpose: Column-selected read of deletedrecord — auto-generated from field metadata
-- Grain : One row per record — see the Fields section for the full key
-- Caution: this ledger records deleted RECORDS, not deleted LINES — a line removed from a surviving transaction never appears here, so line tables need a periodic full refresh; see quirks #deletes.
-- Notes : Auto-generated skeleton for NetSuite data landed in your lakehouse from a SuiteAnalytics Connect (or SuiteQL) extract — it never addresses live NetSuite. Identifiers are lowercase as NetSuite2.com renders them. Select-type columns hold numeric internal ids: BUILTIN.DF() display resolution exists only at extraction time, so decode ids by joining the landed list records; see quirks #display-values. Check-box columns arrive as 'T'/'F' strings; see quirks #tf-booleans.
-- ============================================================
SELECT
t.recordtypeid AS "Record type deleted, as text",
t.type AS "Type of the deleted record, as text",
t.name AS "Name of the deleted record",
t.scriptid AS "Script id of the deleted record",
t.deleteddate AS "When the record was deleted",
t.deletedby AS "Who deleted it (internal id)",
t.context AS "Context the deletion came from (internal id)",
t.iscustomrecord AS "Deleted record was a custom record", -- 'T'/'F' string — compare = 'T', or CAST via CASE; see quirks #tf-booleans
t.iscustomlist AS "Deleted record was a custom list", -- 'T'/'F' string — compare = 'T', or CAST via CASE; see quirks #tf-booleans
t.iscustomtransaction AS "Deleted record was a custom transaction" -- 'T'/'F' string — compare = 'T', or CAST via CASE; see quirks #tf-booleans
FROM <catalog>.<schema>.deletedrecord t
WHERE
1 = 1 -- no partition column on this record; the filters below are optional
-- AND t.deleteddate >= TIMESTAMP '<DATE_FROM>'
-- AND t.deleteddate <= TIMESTAMP '<DATE_TO>'
-- no lastmodifieddate on this record — there is no watermark column, so incremental extraction must full-refresh it (see quirks #deletes)
;Verified August 2026 · Analytics Browser 2021.1 · corroborated 2025.2
Select columns hold internal ids, not display text — see decoding display values.
Relationships
Diagram of 1-hop neighbors — join details below. Document-link edges are highlighted; they chain one document to the next and are the joins newcomers most often get wrong.
More Platform tables
- systemnoteThe field-level change log: one row per record, field and change, with who changed it, in what context, and the old and new values as text.
- systemnote2The second-generation change log: the same field-level history as systemnote, but with the old and new values split into typed columns — string, numeric, date, boolean and reference — beside a UTC change timestamp.