---
title: "Delete Data"
url: "https://help.flows.world/en/article/delete-data"
language: "en"
last_updated: "2026-09-21T08:54:33.164Z"
---

# Delete Data

## Overview

**Delete Data** removes stored data from persistent storage, either deleting specific records or entire groups at once. Use this stage to clean up temporary data, implement data retention policies, or remove sensitive information after processing.

![](https://cdn-assets.productfruits.com/a766618a-641f-40ac-b0fc-8325c23efadb)

\* Example flow demonstrating how **Delete Data** removes a stored key and how **Fetch Data** returns the configured default value when the key is no longer available.

**Note:** The variable names, values, criteria, and configuration used in this example are for demonstration purposes only.

**Where to find it:** *Actions > Local Storage* in the stage library.

## Configuration

### Required Fields

| Field | Description | Example |
| --- | --- | --- |
| **Group name** | The name of the group containing the data to delete (must match group name from Save Data) | `UserSessions`, `TempCache` |

### Optional Fields

-   **Record name:** The specific record to delete within the group. If empty, deletes ALL records in the group.
-   **Key:** Specific key within a record to delete (allows deletion of individual fields instead of entire records).

**Using functions in these fields:** Any value field above accepts `@` functions, for example `@NowSecond` for the current time or `@calc(...)` for a calculation. 

See [Flows Functions](https://help.flows.world/en/article/flows-functions) for the full list.

## Exit Points

| Exit | When |
| --- | --- |
| **Pass** | Deletion completes successfully (even if no matching data was found) |
| **Error** | Only for a failure before the delete runs (e.g. a variable that can't resolve). A *database* error does NOT reach this exit |

**Important:** a database or storage error during the delete does **not** route to the Error exit. It is handled internally and the stage still takes **Pass**. The error is logged and notified, but the flow continues down the green path. To confirm a delete actually happened, follow with a Fetch Data stage and check the data is gone.

## How It Works

When executed, the stage:

1.  **Resolves configuration** - Evaluates group name, record name, and key from variables
2.  **Determines scope** - Decides what to delete based on provided fields
3.  **Executes deletion** - Removes data from persistent storage
4.  **Clears cache (if specified)** - Optionally clears distributed cache across servers

## Deletion Scope

| Fields Provided | What Gets Deleted | Example |
| --- | --- | --- |
| Group name only | ALL records in the entire group | Delete all user sessions |
| Group + Record name | That specific record within the group | Delete session for user\_12345 |
| Group + Record + Key | That specific field within the record | Delete email field from user record |
| Group + Key (no Record) | That key from ALL records in group | Delete phoneNumber from all users |

## Common Use Cases

### 1\. Clean Up Temporary Data

Remove temporary processing data after flow completion.

-   **Group name:** `TempProcessing`
-   **Record name:** `{{processId}}`

### 2\. Delete User Session

Remove user session data after logout.

-   **Group name:** `UserSessions`
-   **Record name:** `{{sessionId}}`

### 3\. Clear Entire Group

Delete all records in a group (e.g., clear all test data).

-   **Group name:** `TestData`
-   **Record name:** (leave empty)

### 4\. Remove Sensitive Data

Delete specific sensitive fields after processing.

-   **Group name:** `CustomerData`
-   **Record name:** `{{customerId}}`
-   **Key:** `creditCardNumber`

## Cache Clearing

Prefix the group name with `cache(60)::` to clear distributed cache across all servers:

**Example:** `cache(60)::UserData`

This will:

-   Delete the data from storage
-   Clear the value from local memory cache
-   Send message to all servers to clear their cached copies

## Key Behaviors

| Feature | Behavior |
| --- | --- |
| **Idempotent** | ✓ Deleting non-existent data succeeds (no error) |
| **Immediate** | ✓ Deletion is permanent and immediate (no undo) |
| **Case-Sensitive** | ✓ Group, record, and key names must match exactly |
| **No Confirmation** | ✓ No "are you sure" prompt - use with caution |
| **Output Variables** | ✗ Does not create output variables (success shown by Pass exit) |

## Best Practices

-   ✓ Use specific record names instead of deleting entire groups when possible
-   ✓ Implement data retention policies with Delete Data and Run later stages
-   ✓ Use `cache(60)::` prefix when deleting frequently accessed data
-   ✓ Test deletion logic with temporary groups before applying to production data
-   ✓ Document which flows delete data from shared groups
-   ✓ Use Route Flow before Delete Data to verify conditions before deletion
-   ✓ Connect Error exit to handle database connection failures

## Common Mistakes

| Mistake | Symptom | Fix |
| --- | --- | --- |
| Deleting entire group unintentionally | All records in group deleted instead of one | Always specify record name to delete specific records |
| Case mismatch in group/record names | Data not deleted (no error, but nothing happens) | Ensure exact case match with names used in Save Data |
| Expecting confirmation or count | No feedback on what was deleted | Use Fetch Data after Delete to verify deletion succeeded |
| Not handling Error exit | Flow fails silently when database unavailable | Connect Error exit to handle failures (retry, alert, log) |
| Forgetting cache clear for hot data | Deleted data still served from cache | Use `cache(60)::` prefix when deleting cached data |

## Troubleshooting

| Issue | Exit/Result | Common Cause | Fix |
| --- | --- | --- | --- |
| Data not deleted | Pass (but data still exists) | Case mismatch in group/record/key names, or wrong data store | Verify exact names match Save Data; check data store ID |
| Delete failed but flow continued anyway | Pass (error swallowed) | A database/storage error is handled internally, so the stage passes instead of taking the Error exit | Check logs for the storage error; use Fetch Data after Delete to confirm the data is actually gone |
| Too much data deleted | Pass | Record name left empty (deleted entire group) | Always specify record name unless you intend to delete all records |
| Cached data still appearing | Pass (but stale cache) | Cache not cleared when data deleted | Use `cache(60)::` prefix in group name |

## Related Stages

-   [**Save Data**](https://help.flows.world/en/article/save-data)**:** Store data that can later be removed with Delete Data.
-   [**Fetch Data**](https://help.flows.world/en/article/fetch-data)**:** Retrieve stored data or verify during testing that deletion succeeded.
-   [**Query Data**](https://help.flows.world/en/article/query-data)**:** Find stored records before deciding what should be deleted.
-   [**Route Flow**](https://help.flows.world/en/article/route-flow)**:** Check conditions before allowing a deletion.
-   [**Run Later**](https://help.flows.world/en/article/run-later)**:** Schedule cleanup logic for a later time.
