How TaskJuice handles your run data

When a workflow runs, TaskJuice records what happened so you can inspect, debug, and replay it. That record is useful precisely because it captures real values: the trigger payload, each step's input and output, and the result. The same detail that makes a run easy to debug is the detail you most want to control. This page explains what gets stored, how long it lives, and the two tools you have for keeping sensitive values out of that history.

What counts as run data

A single run produces two kinds of data, and they are governed differently.

Execution data is the per-run record: the trigger payload that started the run, the input and output of every step, the run's status and timing, and any error a step returned. This is what you read on a run's detail page when you debug a failure. It lives in a high-volume data store separate from your account configuration, and it expires on a fixed retention window tied to your plan.

Account and configuration data is everything you author: your workspace, your workflows and their published versions, your connections, and your redaction rulesets. This data persists for the life of your account because removing it would break your live workflows. It is not subject to the per-run retention window.

The distinction matters when you reason about exposure. A credit card number that flows through a step lands in execution data, where it will age out on the retention window. The redaction rulesets you author to scrub that number are configuration data, which stays. You are deciding, in advance, what the temporary record is allowed to contain.

How long run data is kept

TaskJuice keeps execution data for a fixed number of days, set by your plan. When a run's record reaches the end of that window, it is deleted automatically. You do not schedule or trigger this cleanup, and there is no setting to extend it beyond your plan's window.

This is the only retention number TaskJuice commits to publicly, and it is the same one stated in the Privacy Policy. After the window passes, a run and its step-by-step detail are gone. If you need a run's data to live longer than your plan's window, capture what you need before it expires: read it on the run detail page while the run is still in retention, or write the value you care about to a destination your workflow controls.

TaskJuice acts as a data processor for the payload data your workflows move between third-party services. It does not read, use, or analyze the content of your workflow payloads for its own purposes. The retention window above is about how long the operational record of a run is available to you, not a license for anyone else to inspect it.

Redaction rulesets: scrubbing values before they are stored

A redaction ruleset is a named, versioned library of find-and-replace rules that TaskJuice applies to the data passing through a workflow. When a rule matches a string value, the value is replaced with the literal text you specify before that data is written to your run history or handed to downstream steps. The original value is never recorded.

Rulesets are authored once per account and referenced by name from your workflow hooks. There is no separate redaction settings screen. You define a ruleset, then point a workflow's lifecycle hook at it with the ruleset picker in the editor. Only an account administrator can create or edit a ruleset, and every ruleset is scoped to your account, so one workspace cannot see or apply another account's rules.

Where a ruleset runs

Each rule declares a scope that controls when it fires:

A rule with scope both is the safest default for a value you never want recorded in either direction, such as an authorization header or a national ID number that appears in both a request and its response.

What a rule looks like

A ruleset's rules field is an array of objects. Each object has a pattern to match, a replacement to substitute, and a scope. Here is a ruleset that masks three field values in both directions:

[
  { "pattern": "ssn", "replacement": "[REDACTED-SSN]", "scope": "both" },
  { "pattern": "authorization", "replacement": "[REDACTED]", "scope": "both" },
  { "pattern": "card_number", "replacement": "[REDACTED-PAN]", "scope": "output" }
]

The replacement is literal text. TaskJuice substitutes exactly the string you write, with no variable interpolation or template expansion. If you put [REDACTED] in the replacement, the recorded value is the eight characters [REDACTED], every time.

Field constraints

The ruleset and its rules are validated when you save. These are the hard limits:

How versioning works

Rulesets are append-only with a status flag rather than edited in place. When you change a ruleset, TaskJuice writes a new row at the next version number and flips the previous version to superseded. Exactly one version of a given name is active at a time, and your workflow hooks always resolve the active version by name. You never edit a live ruleset out from under a running workflow; you publish a new version, and the next run picks it up.

This append-only design gives you a record of what each version did, since the changelog field is required on every save. If a redaction rule was too broad or too narrow last month, the superseded version is still there to explain the change.

Account-level rulesets versus trigger-level redaction

There are two redaction surfaces, and they solve different problems. Account-level redaction rulesets, the subject of this page, are reusable across many workflows and apply at your workflow's lifecycle hooks, in either direction, for any data the workflow touches. Trigger-level PII redaction is configured on a single webhook trigger and scrubs field values out of the incoming body before that body reaches $trigger. See webhook advanced settings for the trigger-level option.

Reach for a ruleset when the same set of sensitive fields shows up across several workflows, or when you need to scrub a value on the way out of a step and not just on the way in. Reach for trigger-level redaction when the only place a value needs scrubbing is the inbound payload of one specific webhook.

A failure to plan for: a pattern that does not match

The most common redaction mistake is a rule that silently matches nothing. Patterns are matched against string values reached as TaskJuice walks the data, and a pattern that does not contain ** and stays under 256 characters will save without error even if it never matches a real field. There is no warning at save time that a rule found no targets.

If a value you expected to be scrubbed shows up unredacted in a run, the rule did not match. Check three things, in order. First, confirm the ruleset's active version is the one your workflow hook references by name, since a superseded version is not applied. Second, confirm the scope covers the direction you are looking at; an input-only rule will not touch a step's output. Third, confirm the pattern actually matches the value as it appears in the run, not as you imagine it: a pattern written for creditcard will not match a field carrying credit_card. Adjust the pattern, save a new version, and replay the run to confirm.

Limits worth knowing

Redaction operates on string values during a structured walk of the data. A pattern matches text; it does not understand field semantics, so a value that arrives in an unexpected shape, base64-encoded or nested inside an opaque blob, will pass through untouched. Patterns cannot contain **, and both pattern and replacement are capped at 256 characters each. Redaction does not undo or shorten the retention window; it changes what a run records, not how long the record lives. And because redaction is applied before storage, it cannot retroactively clean runs that were recorded before the rule existed.

Related

• How credentials are stored explains why a connection's secret value never reaches the browser or a run record in the first place.
• The run model covers what a run is, its statuses, and how replay reuses recorded data.
• Read a run's detail shows where execution data appears while a run is still inside its retention window.