All Collections
Property Redaction and Low Logging
Property Redaction and Low Logging

Prevent logging of data for security or performance

Daniel Chilcott avatar
Written by Daniel Chilcott
Updated over a week ago

Property Redaction

By default, all Properties passed as inputs to a Node and returned as outputs are logged in the Activity Logs

However, sometimes it's necessary to prevent sensitive information from being logged. For these scenario's, Flowgear supports Property-level redaction.

To access this feature, click a Property on a Node (includes Custom Properties and Variable Bar Properties), then selected the Redacted option in the overlay that appears. This applies to both input and output Properties and the value stored in the Activity Logs will be the text (Redacted).

When this feature is used, the values of Redacted Properties will not be stored in persistent storage.

Note that although there is no persistent storage of these Properties, they will be stored in the clear on the host executing the Workflow. It is also possible that they will remain in memory after completion of a Workflow due to .NET Garbage Collection policy. Additionally, it is also possible that this memory could be saved to disk within a swap file.

Activity Logging Levels

Workflow Activity Log options are accessed from the Workflow Design Settings Pane.

Two options are provided here - Full Logging and Low Logging. By default, all Workflows are set to Full Logging. The logging setting chosen affects Workflows activated via Always On, Run Now or via API. When running a Workflow in the Workflow Design Pane, Full Logging is always used.

To determine what logging mode was in effect when a Workflow ran, look at the Logging element of the InitialisationXml Property on the first Workflow Activity Log. Note that this only reflects the logging level on the topmost Workflow. If a sub-Workflow was invoked via the Workflow Node, the logging level specified on that Workflow will be used. This behavior permits more granular management of logging. Specifically, logging can be set to Full Logging on a sub-Workflow that requires troubleshooting.

Consider using Low Logging in the following scenarios:

The Workflow is frequently executed

If a particular Workflow is frequently executed, it's usually unnecessary to log normal behavior. Using Low Logging enables errors to be more easily located in the Activity Log Pane. Low logging should also be used on sub-Workflows that execute frequently to avoid unnecessary verbosity.

The Workflow runs often and needs to run very quickly

activity logs are persisted asynchronously but if your Site is very busy, they may be forced to commit synchronously. In this scenario, the Workflow execution will be halted while the logs are being written thus increasing execution time.

The Workflow processes large amounts of data

Where large amounts of data are processed (especially when they're processed using iterators like Splitter), it is recommended that logging be set to Low Logging. In such cases, the time to persist the logs exceeds the execution time of the operation itself. Thus, using Low Logging can provide a substantial performance boost to these Workflows.

Did this answer your question?