Hide execution data

What hiding execution data does

Hiding execution data in Duaer keeps people from seeing the input and output stored on an execution. An execution normally keeps each node’s input and output so you can debug. If that record holds customer details, tokens, or amounts, anyone who can open the digital organization can see them.

Turning execution history off used to be the only option, and then you also lost success and failure. Hiding execution data keeps status, timing, and node names, and hides the payload. This is about what a person sees when they open the record. It is not encryption at rest, and it does not stop a node from passing data to the next step.

The instance setting requires a plan that includes data redaction. Without it, Security tells you to upgrade.

Turn it on for one digital organization

Changing this organization’s settings requires permission to enable or disable data redaction. Instance owners and project admins have that by default.

1. Open the digital organization, use the three dots at the top right, and open Settings.
2. Find Redact production execution data. Runs started by live triggers use this, including webhooks, schedules, and other triggers while the organization is active. Choose Redact to hide them. Default - Do not redact leaves them visible.
3. Redact manual execution data covers runs you start with Execute in the editor. You can turn that on only when production runs are hidden as well.

When the organization uses end-user credentials, production execution data is always hidden. You cannot turn that off for debugging.

Set a floor for the whole instance

Instance owners and instance admins can stop relying on each digital organization’s own switches. Go to Settings, then Security, then Data redaction. Turn on Enforce data redaction and choose a scope.

• Production executions (recommended): every production run is hidden. Manual runs still follow that organization’s own setting. Live data stays covered, and test data can stay visible while you debug.
• Manual and production executions: both are hidden. Use this when test data is sensitive too.
• Manual executions: only manual runs are enforced.

Enforcement applies when someone reads execution data. A digital organization that did not turn hiding on still has its record hidden if the run falls inside the enforced scope.

One organization’s settings cannot be looser than the instance floor. The affected switches lock, and the public API rejects a looser policy. An organization can still be stricter than the floor.

While enforcement is on, a new digital organization starts at that floor. Organizations that already exist keep the settings stored on them. If you later turn enforcement off, they go back to those settings. While enforcement is on, reads still hide data at the floor.

Someone with permission to manage data redaction cannot set an organization below the floor. After instance enforcement is turned off, they can change each organization’s own settings again.

What an execution record still shows after hiding

In the execution view, the data tables are replaced by Data redacted. You still see node names, success or failure, timing, and the shape of the diagram.

• Each node’s input and output json is replaced with an empty object.
• Files and images in binary are removed.
• Fields a node author marks as sensitive (sensitiveOutputFields) stay hidden. Someone who is allowed to reveal data still does not get those fields. On webhook and form triggers, authorization headers and cookies are in that set.
• Error detail keeps the error type, and the HTTP status code for API errors. The message text is not kept, so the sentence cannot carry data out.

Reveal hidden execution data for one run

If the execution used dynamic credentials, credentials resolved at runtime for an end user, the reveal is denied no matter what permission you have. A redacted execution also cannot be pinned back into the editor.

The audit log records a successful reveal, a denied reveal, and a change to the instance enforcement policy. Those events can go to the log streaming you already use.

1. Open the execution.
2. Select Reveal data in the redacted area.
3. The confirmation says the view is written to the audit log, that you should reveal only when you need to, and that unnecessary access may break your own rules.
4. After you confirm, that execution’s data is visible in the current session.

What hiding execution data does not cover

• console.log in a Code node is not hidden. Manual runs show it in the editor logs. Production runs send it to the server’s standard output and to whatever logging you attach there.
• Data still moves between nodes. Hiding only changes what a person sees when they open the execution. It does not stop the digital organization from sending data to an external system.
• A webhook response returned to the caller is the raw body, not a hidden copy.
• Outbound request headers, including authentication headers, are not rewritten because execution data is hidden.
• You cannot hide individual fields. A hidden node loses its whole payload. The exception is fields the node declares as sensitive. Those stay hidden.
• Execution data in the database is not rewritten or encrypted. Hiding happens when the API serves the data. Anyone who can read the database can still read the stored values.
• Instance enforcement is a policy of this instance. Source control does not carry it to another instance. Whether a pushed digital organization hides data there depends on that instance.