spreadsheet/delete FormID SP02

When to Use

• Temp/staging spreadsheet cleanup: A data pipeline creates a staging spreadsheet at the start of a run (via spreadsheet/create) to buffer intermediate data. After all data has been processed and committed to the final destination, spreadsheet/delete removes the staging file to avoid accumulating stale temporary files in Drive.
• Data retention policy enforcement: A compliance workflow identifies spreadsheets older than the company's data retention period (e.g. 7 years for financial records) and permanently deletes them as part of a formal data lifecycle management process, gated by a compliance officer approval step.
• Client offboarding: When a client's contract expires and all data has been exported to the company's own archive systems, a workflow deletes the client-specific analytics spreadsheet as part of the data deletion required by GDPR or other privacy regulations. This step follows a formal approval gate and an audit log write.
• Test environment teardown: Automated integration tests create throwaway spreadsheets during setup. The test teardown phase calls spreadsheet/delete for each spreadsheet ID created during the test run, keeping the test Google account clean.
• Self-expiring report files: Reports generated for a specific event (e.g. a conference, a sales campaign) are automatically deleted 90 days after generation by a scheduled workflow that reads spreadsheet IDs from an expiry registry and calls spreadsheet/delete for each expired entry.

Configuration

Validation Errors

Output Fields

Sample Configuration

{
  "resource": "spreadsheet",
  "operation": "delete",
  "CredentialId": 12,
  "SpreadsheetId": "{{ $json.stagingSpreadsheetId }}"
}

In production scenarios, SpreadsheetId should always come from a Variable node or database record — never a hardcoded string — to prevent accidental deletion of the wrong file.

Sample Output

{
  "spreadsheetId": "1Xt4QzpNnFMdKvBdBZjgmRk9VE2upms7qptlbs74OgVE",
  "deleted": true,
  "status": "success",
  "resource": "spreadsheet",
  "operation": "delete"
}

Expression Reference

Assuming this node is named deleteStaging in the workflow:

Node Policies & GuardRails

• Always export data first: Before deleting any spreadsheet that contains user data or business records, execute a full data export. Use sheet/get for each tab to read all rows, write them to a long-term archive, and only call spreadsheet/delete after the archive writes are confirmed successful on the success port.
• Environment guard — mandatory for production: Add an IF node before this operation: {{ $env.ALLOW_SPREADSHEET_DELETE == "true" }}. If the environment variable is not set or is false, the workflow routes to a notification node instead of deleting. This prevents accidental deletions when workflows run in testing or staging contexts.
• Human approval gate: For spreadsheets containing business-critical or user-generated data, add a Human-in-the-Loop (HIL) approval step before spreadsheet/delete. The workflow pauses and sends an approval request to a designated manager. The delete only fires if explicitly approved.
• Audit trail: Always write a record to your audit database or logging system immediately before calling spreadsheet/delete. Include: the spreadsheet ID, title (fetch it first if needed), the triggering workflow ID, the requesting user, and the timestamp. This log is your only record after the file is gone.
• Trash recovery window: The deleted spreadsheet moves to Google Drive Trash, where the file owner can restore it for up to 30 days. After 30 days, it is permanently and irrecoverably purged. Communicate this recovery window to stakeholders in your runbook.
• SpreadsheetId source: Never hardcode a SpreadsheetId in a spreadsheet/delete node in a production workflow. Always read it from a verified source: a database record written when the spreadsheet was created, or a Variable node set earlier in the same workflow run. Hardcoded IDs are an audit and safety risk.
• Error port handling: The error port of this node must always be connected to a logging and alerting node. A failed delete (e.g. due to permission error) leaves the file intact — but a silent failure means the caller believes the file is gone when it is not. Both outcomes require human attention.
• Quota: One Google Drive API request per delete call. Drive API has its own quota (1000 requests per 100 seconds per user) separate from the Sheets API quota.

Safe Delete Pattern

The following node sequence represents the recommended safe pattern for any production spreadsheet deletion workflow:

// Step 1 — Fetch and log spreadsheet metadata before deletion
// HttpRequest: GET https://www.googleapis.com/drive/v3/files/{{ $json.spreadsheetId }}?fields=name,createdTime,modifiedTime

// Step 2 — Export all data to archive
// For each sheet tab: sheet/get → sheet/append to archive spreadsheet

// Step 3 — Write audit log entry to database
// Database node: INSERT INTO deletion_audit (spreadsheet_id, title, deleted_by, deleted_at, archive_spreadsheet_id) VALUES (...)

// Step 4 — Approval gate (if required by policy)
// HIL node: "Approve deletion of {{ $json.title }}?" → wait for manager approval

// Step 5 — Environment check
// IF: {{ $env.ALLOW_SPREADSHEET_DELETE == "true" }}

// Step 6 — spreadsheet/delete
{
  "resource": "spreadsheet",
  "operation": "delete",
  "CredentialId": 12,
  "SpreadsheetId": "{{ $json.spreadsheetId }}"
}

// Step 7 — Log deletion result
// Database node: UPDATE deletion_audit SET confirmed_deleted=true WHERE spreadsheet_id=...

// Step 8 — Notify stakeholders
// Email / Slack: "Spreadsheet {{ $json.title }} has been deleted. Archive: {{ $output.archiveStep.spreadsheetUrl }}"

Workflow Examples

Example 1 — Pipeline Staging Cleanup

// At the end of a data transformation pipeline
// Only runs after all final writes have confirmed success on the success port
{
  "resource": "spreadsheet", "operation": "delete",
  "CredentialId": 15,
  "SpreadsheetId": "{{ $output.createStaging.spreadsheetId }}"
}
// createStaging is the spreadsheet/create node that ran at pipeline start
// spreadsheetId flows through the entire pipeline via output references

Example 2 — GDPR Client Data Erasure

// Trigger: Client erasure request received and approved via HIL
// After export to company archive is confirmed:
{
  "resource": "spreadsheet", "operation": "delete",
  "CredentialId": 12,
  "SpreadsheetId": "{{ $json.clientSpreadsheetId }}"
}
// Previous nodes: fetch metadata, export all data, write audit log, HIL approval
// Next nodes: update CRM record (spreadsheetId = null), send erasure confirmation email