|
| 1 | +--- |
| 2 | +title: Execution data redaction |
| 3 | +description: Control the visibility of execution data in workflows to protect sensitive information and meet compliance requirements. |
| 4 | +contentType: howto |
| 5 | +--- |
| 6 | + |
| 7 | +# Execution data redaction |
| 8 | + |
| 9 | +Execution data redaction lets you hide the input and output data of workflow executions. This helps protect sensitive information like personal data, authentication tokens, and financial records from being visible to users who can view the workflow but don't need to see the underlying data. |
| 10 | + |
| 11 | +When redaction is enabled, execution metadata (status, timing, node names) remains visible, but the actual data payload processed by each node is replaced with a redacted indicator. |
| 12 | + |
| 13 | +## Why use execution data redaction |
| 14 | + |
| 15 | +Workflows often process data that the workflow builder or viewers should not have access to outside of n8n. Common scenarios include: |
| 16 | + |
| 17 | +- **Dynamic credentials**: End users authenticate through workflows, and their data flows through execution logs that the builder can freely view. |
| 18 | +- **PII and compliance**: Workflows handling customer personal data (emails, addresses, financial records) need to comply with GDPR, SOC 2, or internal security standards. |
| 19 | +- **Cross-department workflows**: A workflow built by one team processes sensitive data from another team that the builder would not normally have access to. |
| 20 | +- **Least privilege principle**: Limiting data visibility to only those who need it, rather than everyone with workflow view access. |
| 21 | + |
| 22 | +Previously, the only option was to disable execution history entirely at the workflow level, which removed all visibility into workflow success or failure status. Execution data redaction preserves execution monitoring while hiding the sensitive data payload. |
| 23 | + |
| 24 | +## Configure redaction settings |
| 25 | + |
| 26 | +Redaction is configured per workflow in the workflow settings. You need the **Manage data redaction** (`workflow:updateRedactionSetting`) scope to change these settings. |
| 27 | + |
| 28 | +To configure redaction: |
| 29 | + |
| 30 | +1. Open your workflow. |
| 31 | +2. Select the **three dots icon** <span class="n8n-inline-image">{.off-glb}</span> in the upper-right corner. |
| 32 | +3. Select **Settings**. |
| 33 | +4. Find the **Redact production execution data** and **Redact manual execution data** settings. |
| 34 | +5. For each setting, choose either **Default - Do not redact** or **Redact**. |
| 35 | +6. Select **Save**. |
| 36 | + |
| 37 | +### Redaction settings explained |
| 38 | + |
| 39 | +There are two independent toggles that control redaction: |
| 40 | + |
| 41 | +| Setting | What it controls | |
| 42 | +| ------- | ---------------- | |
| 43 | +| **Redact production execution data** | Controls whether data from production (non-manually triggered) executions is redacted. Production executions are those triggered by webhooks, schedules, or other triggers when the workflow is active. | |
| 44 | +| **Redact manual execution data** | Controls whether data from manually triggered executions is redacted. Manual executions are those started by selecting **Execute Workflow** in the editor. | |
| 45 | + |
| 46 | +These two toggles combine into a single `redactionPolicy` stored on the workflow: |
| 47 | + |
| 48 | +| Production | Manual | Resulting policy | |
| 49 | +| ---------- | ------ | ---------------- | |
| 50 | +| Do not redact | Do not redact | `none` - No redaction applied to any executions | |
| 51 | +| Redact | Do not redact | `non-manual` - Only production executions are redacted | |
| 52 | +| Do not redact | Redact | `manual-only` - Only manual executions are redacted | |
| 53 | +| Redact | Redact | `all` - All executions are redacted | |
| 54 | + |
| 55 | +### Dynamic credentials |
| 56 | + |
| 57 | +Workflows that use dynamic credentials always have their production execution data redacted, regardless of the redaction setting. This is because dynamic credential executions process data on behalf of end users, and the workflow builder should not be able to view that data. |
| 58 | + |
| 59 | +When a workflow uses dynamic credentials, the **Redact production execution data** setting is locked to **Redact** and cannot be changed. |
| 60 | + |
| 61 | +## What redacted data looks like |
| 62 | + |
| 63 | +When an execution is redacted: |
| 64 | + |
| 65 | +- All input and output data for each node is replaced with an empty object. |
| 66 | +- Binary data (files, images) is removed. |
| 67 | +- Error messages are redacted, preserving only the error type and HTTP status code (for API errors) to aid in troubleshooting. |
| 68 | +- The execution viewer displays a **"Data redacted"** indicator with a shredder icon instead of the usual data tables. |
| 69 | +- Execution metadata remains visible: node names, execution status (success/failure), timing information, and the workflow structure. |
| 70 | + |
| 71 | +/// note | Error information |
| 72 | +When execution data is redacted, error details are also redacted to prevent sensitive information from leaking through error messages. Only the error type (for example, `NodeApiError`) and HTTP status code are preserved. This provides enough information to identify the category of failure without exposing data. |
| 73 | +/// |
| 74 | + |
| 75 | +## Reveal redacted data |
| 76 | + |
| 77 | +Users with the **Reveal execution data** (`execution:reveal`) scope can temporarily view redacted execution data for a specific execution. Instance owners and admins have this scope by default. |
| 78 | + |
| 79 | +To reveal data: |
| 80 | + |
| 81 | +1. Open the execution in the execution viewer. |
| 82 | +2. Select the **Reveal data** button displayed in the redacted data area. |
| 83 | +3. Review the confirmation dialog. It explains that: |
| 84 | + - The action will be logged in the audit trail. |
| 85 | + - You should only reveal data if you have a legitimate reason. |
| 86 | + - Unnecessary access may violate your organization's policy. |
| 87 | +4. Select **Reveal data** to confirm. |
| 88 | + |
| 89 | +The execution data becomes visible for that execution in the current session. |
| 90 | + |
| 91 | +/// warning | Dynamic credential executions can't be revealed |
| 92 | +Executions that used dynamic credentials can't be revealed, even by users with the `execution:reveal` scope. This is a security measure to protect end-user data that flows through workflows using dynamic credential resolution. |
| 93 | +/// |
| 94 | + |
| 95 | +### Audit logging |
| 96 | + |
| 97 | +All reveal actions are tracked through [log streaming](/log-streaming.md). Two audit events are available: |
| 98 | + |
| 99 | +| Event | Description | |
| 100 | +| ----- | ----------- | |
| 101 | +| `execution.data.revealed` | Emitted when a user successfully reveals redacted execution data. Includes the user, execution ID, workflow ID, timestamp, IP address, and the redaction policy in effect. | |
| 102 | +| `execution.data.revealed_failure` | Emitted when a reveal attempt is denied (for example, due to insufficient permissions). Includes the same fields plus the rejection reason. | |
| 103 | + |
| 104 | +These events integrate with your existing log streaming destinations (syslog, webhooks, Sentry) and can be used for compliance reporting and access auditing. |
| 105 | + |
| 106 | +/// note | Fail-closed behavior |
| 107 | +If the audit system is unavailable when a reveal is attempted, the reveal is denied and a `503 Service Unavailable` error is returned. This fail-closed behavior ensures that all data access is auditable. |
| 108 | +/// |
| 109 | + |
| 110 | +## Permission scopes |
| 111 | + |
| 112 | +Execution data redaction introduces two permission scopes that can be assigned through [custom project roles](/user-management/rbac/custom-roles.md): |
| 113 | + |
| 114 | +| Scope | Purpose | |
| 115 | +| ----- | ------- | |
| 116 | +| `workflow:updateRedactionSetting` | Allows modifying the redaction policy in workflow settings. Displayed as **Manage data redaction** in the role configuration UI. | |
| 117 | +| `execution:reveal` | Allows revealing redacted execution data. Instance owners and admins have this scope by default. | |
| 118 | + |
| 119 | +Apply the principle of least privilege when assigning these scopes: |
| 120 | + |
| 121 | +- Grant `workflow:updateRedactionSetting` to project admins or security leads who define data access policies. |
| 122 | +- Grant `execution:reveal` sparingly, typically to a small set of trusted users who may need to troubleshoot production issues involving sensitive data. |
| 123 | + |
| 124 | +## Best practices |
| 125 | + |
| 126 | +### Choosing the right redaction policy |
| 127 | + |
| 128 | +| Scenario | Recommended setting | |
| 129 | +| -------- | ------------------- | |
| 130 | +| Workflows processing PII, financial data, or authentication tokens in production | Redact production execution data | |
| 131 | +| Workflows where even test data is sensitive (for example, using copies of production data) | Redact both production and manual execution data | |
| 132 | +| Workflows processing non-sensitive data, or during initial development | No redaction | |
| 133 | +| Workflows using dynamic credentials | Production data is always redacted automatically | |
| 134 | + |
| 135 | +### General recommendations |
| 136 | + |
| 137 | +- **Start with production redaction**: For most workflows handling sensitive data, redacting production executions while keeping manual executions visible provides a good balance between security and debuggability. |
| 138 | +- **Redact manual data when needed**: If your test environment uses real or production-like data, enable manual execution redaction as well. |
| 139 | +- **Use log streaming**: Enable [log streaming](/log-streaming.md) to capture reveal audit events. This provides an audit trail for compliance and allows you to monitor who is accessing sensitive execution data. |
| 140 | +- **Limit reveal access**: Only grant the `execution:reveal` scope to users who have a legitimate need to view sensitive data in production executions. |
| 141 | +- **Review redaction settings during workflow reviews**: Include redaction policy as part of your workflow review or approval process, especially for workflows that handle cross-department or customer-facing data. |
| 142 | + |
| 143 | +## Security considerations |
| 144 | + |
| 145 | +- Redaction is applied at the API level. Redacted data is not sent to the browser. |
| 146 | +- Nodes can declare specific output fields as sensitive (using `sensitiveOutputFields` in the node type definition). These fields are always redacted and cannot be revealed, even by users with the `execution:reveal` scope. |
| 147 | +- The fail-closed audit design ensures that if logging infrastructure is down, data cannot be silently revealed without a record. |
| 148 | +- Redaction settings are stored as part of the workflow configuration and can be managed through [source control](/source-control-environments/index.md). |
0 commit comments