The Purge Node irreversibly replaces sensitive or unnecessary data in workflow execution records with a ** PURGED ** placeholder. It operates on three independent data categories — form submissions, node output data, and global constants — and lets you control the scope from full wipe-down to individual fields.

Purging targets the stored execution records (the historical data in the database), not the live Data Center values used by the running workflow. This means the Purge Node is a data hygiene tool for completed or in-progress execution history, not a mechanism for clearing runtime state.

The Purge Node does not delete records. It replaces values in-place so that the execution structure (which nodes ran, in what order, with what status) remains intact for auditing, while the actual sensitive content is no longer readable.

When to Use

Use a Purge Node when your workflow needs to:

Remove personally identifiable information (PII) from execution records after the workflow has processed it — for example, wiping employee SSNs, salary data, or medical details once an HR case is resolved.
Comply with data retention policies that require sensitive data to be scrubbed after a defined processing window.
Clear API response payloads that contain credentials, tokens, or third-party data that should not persist in execution history.
Sanitize form submissions before the workflow's execution record becomes visible in reports or audit trails.
Wipe global constant values that were used as temporary secrets during a workflow run (API keys, one-time tokens).

How It Appears on the Canvas

The Purge Node is a standard single node with one incoming edge and one outgoing edge. It does not produce output data for downstream nodes — it runs its purge operations and completes.

Configuration

The Purge Node has three independent purge categories. Each can be enabled or disabled separately, and they run in sequence: form data first, then Data Center node outputs, then global constants.

Form Data Purge

Controls whether and how form submission data stored in execution records is replaced.

Setting	Description
Enable Form Data Purge	Master toggle. When off, no form data is touched regardless of the settings below. Default: off.
Form Purge Type	Determines the scope of the purge.

Purge type options:

Type	Behavior
All Forms	Purges every form's `data` and `dataLabels` across all form submissions in the current workflow execution. Every field value is replaced with ` PURGED `.
Specific Forms	Only purges forms whose identifiers appear in the `specificFormsToPurge` list. Other forms are left untouched.
Specific Fields	Only purges named fields within named forms. You provide a list of `{ form, fields[] }` entries specifying exactly which fields to wipe in which forms. Non-listed fields within those forms are preserved.

How form values are replaced:

The replacement logic handles different field types:

Value Type	Replacement Behavior
Scalar (string, number, boolean)	Replaced with ` PURGED `.
Plain object	Replaced with ` PURGED `.
Array of primitives	Replaced with ` PURGED `.
Array of objects (Field Array type)	Structure preserved — the array remains an array of objects, but each object's inner values are recursively purged. This keeps the row/column structure visible while scrubbing the data.

Both the data (raw values) and dataLabels (display-formatted values) sections of each form are purged in parallel, so labels don't leak information that was wiped from the raw data.

Data Center Purge (Node Outputs)

Controls whether and how node execution output data stored in records is replaced.

Setting	Description
Enable Data Center Purge	Master toggle. Default: off.
Data Center Purge Type	Determines the scope of the purge.
Enable Node Request Data Purge	Additional toggle — when on, the node's stored request payloads and synapse form default values are also purged. Default: off.

Purge type options:

Type	Behavior
All Nodes	Purges execution data for every eligible node in the workflow execution.
Specific Nodes	Only purges nodes whose IDs appear in the `specificNodesToPurge` list.
Specific Keys	Only purges named fields within named nodes. You provide a list of `{ node, fields[] }` entries specifying exactly which Data Center keys to wipe for which nodes.

Eligible node types: Only nodes of type Action, Function, Async Callback, Update, and Mapper are eligible for Data Center purge. Other node types (Trigger, Input, Decision, Delay, loops, etc.) are not touched.

What gets purged in each node:

Record	Purge behavior
Execution data (response)	All values in the node's stored response are recursively replaced with ` PURGED `. Arrays become arrays of ` PURGED `, nested objects become nested ` PURGED `.
Execution mapping data	The `outputField` and `value` in each mapping entry are replaced with ` PURGED `.
Mapper execution mapping data	The `value` in each response mapping entry is replaced with ` PURGED `.
Request data (if request purge enabled)	The entire stored request payload is recursively replaced with ` PURGED `.
Synapse form (if request purge enabled)	Field types are converted to `input`, and non-empty `defaultValue` fields are replaced with ` PURGED `. For Field Array types, nested field types and default values are purged while the structure is preserved.

Global Constants Purge

Controls whether specific global constant values stored in execution records are replaced.

Setting	Description
Enable Global Constants Purge	Master toggle. Default: off.
Specific Constants to Purge	A list of global constant names to purge. Unlike form and Data Center purges, there is no "purge all" option — you must explicitly name which constants to wipe.

What gets purged:

Record	Purge behavior
updatedGlobalConstant	The named constants' values in every workflow node data record that contains global constant updates are replaced with ` PURGED `.
Execution mapping data	Any execution mapping entry whose `formField` matches `globalConstants.<constantName>` has its `outputField` and `value` replaced with ` PURGED `.

How It Works at Runtime

1. Application lookup. The node fetches the current application to determine the activeVersionId, which is used to scope all database queries.

2. Form Data Purge (if enabled). The node queries all WorkflowNodeData records for the current execution that contain form data. Based on the purge type:

All Forms: Every form in every matching record is purged.
Specific Forms: Only forms whose identifiers are in the configured list are purged.
Specific Fields: Only the named fields within the named forms are purged; other fields pass through unchanged.
The purge uses bulk writes with large-object support (for data that may be stored in S3).

3. Data Center Purge (if enabled). The node reads the current Data Center state to get all node IDs, then fetches node details, execution records, and node data records in parallel. Based on the purge type:

All Nodes / Specific Nodes: Execution data is recursively replaced. Execution mapping data and mapper execution mapping data are purged. If request data purge is enabled, stored request payloads and synapse forms are also purged.
Specific Keys: Only the named fields within the named nodes are replaced. The rest of the execution data passes through unchanged.
Updates run concurrently with a concurrency limit of 10.

4. Global Constants Purge (if enabled). The node queries all workflow node data records that contain global constant updates. For each named constant, the value is replaced in the stored records, and the related execution mapping entries are also purged.

5. Completion. The node returns a COMPLETED status. It does not produce any output data — there is no response.data for downstream nodes.

Data Center Output

The Purge Node does not register any output in the Data Center. It produces no data for downstream nodes to reference. Its sole purpose is to modify existing stored records.

What Gets Purged vs. What Doesn't

Purged	Not Purged
Form field values (`data`, `dataLabels`) in WorkflowNodeData records	Live Data Center values in Redis/memory used by the running workflow
Node execution response data in WorkflowNodeData records	Execution metadata (status, timestamps, node type, node ID)
Execution mapping data values in WorkflowNodeExecution records	Workflow structure (node connections, positions, configuration)
Mapper execution mapping data values	Node names, descriptions, and configuration settings
Request payloads (if request purge enabled)	Progress path display and audit trail structure
Synapse form default values (if request purge enabled)	Records for non-eligible node types (Trigger, Input, Decision, Delay, loops)
Global constant values in WorkflowNodeData records

Key distinction: The purge operates on persisted execution records in the database — the data that shows up in execution history, progress paths, and audit logs. It does not affect the live runtime Data Center that subsequent nodes read from during the current execution. This means a node running after the Purge Node can still access the original values in the Data Center for the current run; the purge only affects how those values appear in stored records.

The ` PURGED ` Placeholder

All purged values are replaced with the string constant ** PURGED **. This is a system-wide constant used across all purge operations. It serves as a clear visual indicator in execution records that data was intentionally removed (not accidentally empty or null).

Progress Path

The Purge Node uses the default progress path configuration.

Status	Displayed Fields
Default	Triggered at

Validation Rules

At save time:

All configuration fields are validated using a Joi schema:

Field	Validation
`enableFormDataPurge`	Boolean
`formPurgeType`	String
`specificFormsToPurge`	Array of strings (form identifiers)
`specificFieldsToPurge`	Array of `{ form: string (required), fields: string[] (required) }`
`enableDataCenterPurge`	Boolean
`dataCenterPurgeType`	String
`specificNodesToPurge`	Array of strings (node IDs)
`dataCenterFieldsToPurge`	Array of `{ node: string (required), fields: string[] (required) }`
`enableGlobalConstantsPurge`	Boolean
`specificConstantsToPurge`	Array of strings (constant names)
`enableNodeRequestDataPurge`	Boolean

At runtime:

Empty or missing data is handled gracefully — if no form data exists, or no matching nodes are found, the purge silently skips that category. No errors are thrown for empty targets.

Edge validation:

The Purge Node uses the default (generic) node validation strategy.

Retriggering:

The Purge Node is not eligible for retrigger. Only Action, Function, and While nodes can be retriggered.

Best Practices

Place the Purge Node at the end of your workflow (or at the end of a processing phase). Since it operates on execution records, place it after all nodes that need the data have finished. Purging too early doesn't affect the live Data Center, but it does mean execution logs for already-completed nodes will show ** PURGED ** instead of actual values, making debugging harder if something fails later.
Use Specific Fields / Specific Keys for surgical purges. Wiping all forms or all nodes makes debugging nearly impossible. Purge only what's actually sensitive — PII fields, credentials, API tokens — and leave operational data intact for troubleshooting.
Enable request data purge for integration nodes that receive sensitive payloads. If an Action Node calls an API that returns sensitive data in the response and the request contains credentials or PII, enable enableNodeRequestDataPurge to scrub both sides.
Remember that purge is irreversible. There is no "unpurge" operation. Once a value is replaced with ** PURGED **, the original data is gone from the execution records. Make sure any downstream reporting or audit processes that need the original values have already captured them.
Understand the eligible node types. Only Action, Function, Async Callback, Update, and Mapper nodes are eligible for Data Center purge. If you're trying to purge data from a Trigger or Input node, you'll need to use the Form Data Purge category instead (since those nodes write to forms, not to the node output section of the Data Center).
Use Global Constants Purge for temporary secrets. If your workflow stores an API key or one-time token in a global constant for use during execution, purge it after the workflow completes so it doesn't persist in execution records.
Test purge scope in a staging environment first. Because purge is irreversible and affects execution records across forms, nodes, and constants, verify your configuration against a test execution before deploying to production.