S3 — object/delete

Versioned Buckets: For buckets with versioning enabled, deleting without specifying versionId places a delete marker — the data is still recoverable. To permanently remove a specific version, you must specify its versionId. Use bucket/search to retrieve all version IDs before permanently deleting versioned objects.

When to Use

Temporary file cleanup: Remove processing artifacts and temporary files after a workflow has consumed and transformed them.
GDPR erasure: Permanently delete user-specific data objects to fulfill a right-to-erasure request, including all versions.
Expired cache removal: Delete cached report or asset objects that have exceeded their validity period and need to be regenerated.
Failed upload cleanup: Remove partially uploaded or failed objects that would otherwise be orphaned in the bucket.
Post-copy source cleanup: Delete the source object after a successful object/copy to implement a logical "move" operation.

Configuration

Connection

Credentials and region are not fields on this operation. Wire an S3 Server satellite node into this node's input. The satellite holds the vault credential (ApiKey type — Username = access key ID, Password = secret key), the target AWS region, and an optional Service URL override for S3-compatible backends. Its values are merged onto this node at execution time and take precedence over anything set locally. See S3 Server (satellite) for the full field reference.

Tenant-prefixed: objectKey is auto-prepended with tenants/{tenantId}/ before the request is sent to S3. The value you type is what other S3 nodes in this workflow should reuse; the output's effectiveObjectKey field carries the literal key actually deleted, for use with the AWS console, CLI, or other external tools.

Operation Fields

Field	Required	Description
`bucketName`	Required	Name of the bucket containing the object to delete.
`objectKey`	Required	Full key path of the object to delete.
`versionId`	Optional	Specific version ID to permanently delete. For versioned buckets, omitting this creates a delete marker instead of permanently removing the data.
`bypassGovernanceRetention`	Optional	When `true`, bypasses S3 Object Lock governance-mode retention. Requires `s3:BypassGovernanceRetention` IAM permission. Default: `false`.

Sample Configuration

// Credentials + region resolved from the connected S3 Server satellite — see s3-server-satellite.html
{
  "resource": "object",
  "operation": "delete",
  "bucketName": "acme-processing-temp",
  "objectKey": "{{ $node.ProcessFile.output.tempObjectKey }}",
  "bypassGovernanceRetention": false
}

Validation Errors

Error Code	Cause & Resolution
`AccessDenied`	The IAM identity lacks `s3:DeleteObject` permission. Update the IAM policy. For governance bypass, also add `s3:BypassGovernanceRetention`.
`ObjectLocked`	The object is under S3 Object Lock compliance mode. Compliance-mode locked objects cannot be deleted until the retention period expires, regardless of permissions.
`NoSuchKey`	S3 returns HTTP 204 for deleting a non-existent key (success behavior). The node treats this as success. If you need to detect missing objects, use `bucket/search` first.

Output

Success Port

Field	Type	Description
`status`	string	`success` on successful deletion or when the object did not exist (S3 is idempotent on delete).
`errorCode`	string	Empty string on success.
`bucketName`	string	The bucket from which the object was deleted.
`objectKey`	string	The key of the deleted object, for audit logging.

Error Port

On failure, activates with errorCode, errorMessage, and httpStatusCode. The primary failure cases are AccessDenied and ObjectLocked — both indicate permission or retention policy issues requiring human review.

Sample Output

{
  "status": "success",
  "errorCode": "",
  "bucketName": "acme-processing-temp",
  "objectKey": "temp/session-8f3a2b1c/upload-buffer.bin"
}

Expression Reference

Expression	Result
`{{ $node.DeleteTempFile.output.status }}`	Confirm deletion succeeded before proceeding in cleanup workflows.
`{{ $node.DeleteTempFile.output.objectKey }}`	Deleted key — log to audit trail as evidence of data erasure (GDPR use case).
`{{ $node.DeleteTempFile.output.bucketName }}`	Confirm which bucket the deletion occurred in for multi-bucket workflows.

Node Policies & GuardRails

Policy Area	Recommendation
Credential Storage	Store credentials in BizFirst Credentials Manager. Never hardcode.
IAM Permissions	Grant `s3:DeleteObject` scoped to the specific bucket ARN and key prefix. Never grant wildcard delete on the entire account.
Object Key Expression	Always resolve `objectKey` from a trusted workflow variable — never derive from user input without strict sanitization to prevent unintended deletions.
Versioned Bucket Awareness	For versioned buckets, omitting `versionId` creates a delete marker, not a permanent deletion. Specify `versionId` for true erasure (e.g. GDPR compliance).
GDPR Erasure Pattern	For right-to-erasure workflows, list all versions first with `bucket/search`, then loop through all `versionId`s and delete each individually.
Audit Trail for Erasure	Log `objectKey`, `versionId`, the requesting user identity, and the erasure timestamp to a persistent compliance audit log.
Post-Copy Delete	When implementing a "move" pattern (copy + delete), only execute the delete after confirming the copy succeeded — check `$node.CopyStep.output.status == "success"` in an If Condition before deleting.
Governance Bypass	Never enable `bypassGovernanceRetention` in automated workflows without a documented exception. This capability requires an explicit IAM permission and audit justification.

Examples

Example 1: Post-Processing Temp File Cleanup

After an ETL workflow finishes transforming a file, delete the original temp object from the landing zone.

// Node: CleanupSource (S3 — object/delete)
// Only runs after successful copy to archive (If Condition check)
{
  "bucketName": "acme-ingest-landing",
  "objectKey": "{{ $node.CopyToArchive.output.sourceKey }}"
}
// This implements a safe "move" — copy first, delete only on success

Example 2: GDPR Right-to-Erasure

A compliance workflow permanently removes all versions of a user's documents from S3 after a deletion request is approved.

// Node: ListAllVersions (bucket/search with versioned list)
// Node: EraseVersions (Loop over all versionId values)
// Node: DeleteVersion (S3 — object/delete)
{
  "bucketName": "acme-user-documents",
  "objectKey": "users/{{ $node.ErasureRequest.output.userId }}/{{ $loop.currentItem.key }}",
  "versionId": "{{ $loop.currentItem.versionId }}"
}
// After loop: Log erasure confirmation to compliance audit store

Example 3: Expired Cache Eviction

A scheduled workflow removes report cache objects older than 7 days to force regeneration on next access.

// Node: FindExpiredCacheFiles (bucket/search, prefix: "cache/reports/")
// Node: FilterOldObjects (Code Execute — filter by lastModified < 7 days ago)
// Node: DeleteExpiredCache (Loop → S3 — object/delete)
{
  "bucketName": "acme-report-cache",
  "objectKey": "{{ $loop.currentItem.key }}"
}
// No versionId needed — cache bucket is not versioned

object/delete FormID 20507

When to Use

Configuration

Connection

Operation Fields

Sample Configuration

Validation Errors

Output

Success Port

Error Port

Sample Output

Expression Reference

Node Policies & GuardRails

Examples

Example 1: Post-Processing Temp File Cleanup

Example 2: GDPR Right-to-Erasure

Example 3: Expired Cache Eviction