Audit Trail
Nected keeps a running record of everything that happens inside your workspace - every change anyone makes to a rule, workflow, decision table, rule set, dataset, connector, global variable, system API key, or auth config, and every single time a rule or workflow actually runs. Audit Trail is where all of that lives.
Why it matters?
Two reasons people actually open this screen:
Troubleshooting. Something’s not working right - a rule is returning the wrong value, a workflow stalled halfway through, an integration started failing overnight. Instead of guessing, you pull up the Audit Trail, find the run or the change in question, and see exactly what happened: who touched what, when, and what the system actually did with it.
Security and compliance. Audit Trail also works as a monitoring tool. You can use it to spot users accessing or modifying things they shouldn’t be touching, and to satisfy the kind of “prove you track every change to your systems” requirement that shows up in a lot of industry regulations. Every create, update, publish, and delete gets a timestamp, a user, and an IP address attached to it - nothing happens invisibly.
How to Access the Audit Trail?
In the left sidebar, under SECURITY, click Audit Trail.
It opens the Audit Trail page with two tabs in it: Execution Logs tab and Activity Logs tab.
Activity Logs vs Execution Logs
Everything in Audit Trail lives in one of two tabs, and picking the right one is the first decision you make.
Activity Logs
Execution Logs
Records
Changes to your workspace
Runs of your rules and workflows
A row means
Someone - or something - created, edited, published, or deleted an object
A rule or workflow executed
Rows per run
One for the run, plus one per nested step
One, for the run as a whole
Opening a row gives you
A record card, linked to its parent and children
A replay of the run inside the actual builder
Best for
Accountability, change history, "what did this look like before?"
Debugging, "why did this produce that result?"
Use Activity Logs when the question is about people and history - who changed this rule, who deleted that connector, what did an object look like before an edit.
Use Execution Logs when the question is about behaviour - why a run failed, which condition matched, where a workflow stopped.
The two tabs are linked. A single run writes rows to both: Execution Logs gets one row for the run as a whole, and Activity Logs gets a row for the run and for every nested step inside it. A practical way to use them together: start in Execution Logs to see the run visually and identify the step that went wrong, then copy that step's execution ID into Activity Logs' search to read its record and walk its parents and children.
Each tab keeps its own filter state, so switching between them doesn't reset your work.
Activity Logs
The Activity Log is Audit Trail's record of what happened to your workspace. Every time an object is created, edited, published or deleted, a row appears here. Every time something runs, rows appear here too - one for the run itself and one for each nested step inside it. That makes it the place to answer questions about accountability and history.
To open it, select the Activity Logs tab.
What Does the Activity Logs Screen Show?
Below the tabs sits a filter row, then a count of matching records, then the table itself with pagination underneath. Every filter is covered in Filters.
What Do the Table Columns Mean?
Date
When the event happened, to the minute. The only sortable column.
Type
The kind of object the event belongs to - a rule, a workflow, a connector, an API key, or an individual step inside a run.
Name
The object's name at the time of the event.
Event
What was done - created, updated, published, deleted, or executed.
Status
Success or Error. Run events also carry a duration inside the pill (1ms, 130ms, 1.64s).
Mode
Staging or Production.
User
Who performed it. A dash means no person was involved - the row was generated by a run.
Root Node
The top-level object the event belongs to. This is a link, useful for jumping from a deeply nested step back to the top of its chain.
A single run produces one row for itself and one for every nested step beneath it - that's why a small workspace can accumulate hundreds of activity records.
How Do I Filter Activity Logs?
A search box and four dropdowns sit below the tabs: Type, Event, Status and Mode, plus Start Date and End Date. Type as you type in the search box, tick as many dropdown values as you need, or set a date range - all of them narrow the same table together.
Every option, what each means, and the verified limitations are covered once, for both logs, in Filters below. Two things specific to this screen are worth flagging here:
The Type column shows values the Type filter does not offer, including the step types generated by runs (
Condition,Dbnode,Restapinode,Loop,Switch). You will see them in rows but cannot filter for them.There is no filter on User. It is a column you scan, not a filter you apply, so narrow by Event and date range first to keep the list short enough to read.
How Do I Open a Record?
Click any row to open its record.
The card leads with the object's name and its status, then lists the facts about that one event.
Date
Full timestamp, for example 4:50 PM on 04/09/2026.
Type
The object type.
Version
draft for an unpublished working copy, or a published version number.
Event
What was done.
Mode
Staging or Production.
User
Who did it, or a dash.
IP
Where the request came from.
ID
The unique identifier for this event.
Branch
The Git branch, if Git integration is connected. A dash otherwise.
Message
A system note. Green on success, red on failure.
Like this:
What Is the Input & Output Section?
When the object had Auditing switched on at the time it ran, the record includes a collapsible Input & Output section showing the two payloads side by side. Use the chevron beside the heading to collapse it.
For a decision table, the Output is the most informative part of the whole record. It lists one entry per row of the table, each carrying its row identifier, whether it produced the default output, any row-level error, and the result value - so you can see exactly which row of the table produced what was returned.
If this section is missing from a run record, Auditing was off for that object when it ran. See Auditing.
How Do I Trace Parent and Children Records?
This is how you follow a run step by step without leaving the Activity Log.
A run writes a record for itself and a record for every nested step, and those records are linked. Each one shows its neighbours in the chain as small tables at the bottom of the card:
Parent - the event one level up
Children - the events one level down
Both tables use the same columns as the main list, and every row in them is clickable. That lets you walk the execution tree one record at a time, in either direction.
A real chain, from the top down:
Which tables appear tells you where you are in that chain:
Root - the object you actually ran
Children only
Middle - a rule inside a rule set, a node inside a workflow
Parent and Children
Leaf - a single condition evaluation
Parent only
To jump back to the top of the chain from anywhere, use the Root Node link in the main table rather than clicking Parent repeatedly.
How Do I Compare Changes Between Versions?
Records for rules and decision tables can carry a Compare Changes › button, which opens a version-to-version diff drawn on the rule's own grid rather than on raw JSON.
Version pickers at the top choose the two versions being compared and swap them; counters total what changed; modified cells are tinted, added rows are green, and removed values are struck through.
The button only appears where there is an earlier version to compare against. A record for an object that has only ever been a draft will not show it - in testing, Update records for a draft rule had no Compare Changes button even though the rule had a published version elsewhere.
Full reference: Universal Diff View.
Execution Logs
You ran a rule or a workflow and you need to know what happened during that run - why it returned what it returned, where it failed, or what values it actually used.
Execution Logs does not show you a log file. When you open a run, Nected reopens the rule or workflow itself as it was at that moment, with that run's real values drawn onto it. You investigate by looking at your own logic with the data laid over it.
This section covers the list screen, the execution detail screen shared by every execution type, and then each execution type in turn: Decision Table, Simple Rule, Rule Set, Workflow, and Connector.
What Does the Execution Logs List Show?
Execution Logs is the tab Audit Trail opens on by default - see How to Access the Audit Trail? if you need the steps.
Each row is one execution.
What Do the Columns Mean?
The rest is same as the Activity Log screen. What's more here is as described in the table below:
Source
Internal or External
Internal covers console tests and one object calling another inside Nected; External is your own services calling the API from outside. This is the reliable way to exclude your own testing.
How Do I Find the Execution I Want?
If you just ran it, it's the top row. Otherwise, use the filter row above the table.
How Does Search by ID or Name Work?
Type an object's name, or paste a full execution ID, into the search box above the table. It matches partial text anywhere in the value, ignores case, and updates as you type - no Enter key, no search button.
It also returns runs connected to your match: searching a rule set's name returns the rule set's run and the runs of its member rules.
What Filters Are Available?
Five multi-select dropdowns sit beside the search box: Type, Event, Status, Source and Mode. Tick as many values as you need in each - ticking narrows, and multiple filters combine together, never widening the result.
Two habits worth building immediately:
Tick
ErrorandAction Failedtogether under Status when hunting failures. They are different outcomes, and a run whose post-rule action failed still reports overall success - filtering onErroralone hides it.Use
Source, notMode, to separate real traffic from testing. The Mode filter has a verified problem on this screen and can empty the table even when matching runs exist.
Every option and its meaning - plus the Mode limitation in full - is in Filters below.
What Happens When I Click a Row?
The list is replaced by the execution detail screen. What appears in the middle of that screen depends on what ran:
decisionTable
Decision Table execution
simpleRule
Simple Rule execution
ruleSet
Rule Set execution
workflow
Workflow execution
connector
Connector execution - the one type with no replay
What Does the Execution Detail Screen Show?
Every rule and workflow execution opens into the same four-region screen. Learning it once covers all of them.
Left panel
Execution History - every past run of this same object
Middle
The rule or workflow itself, with this run's values on it
Right panel
Execution Details - the metadata and verdict for this run
The Edit button leaves the replay and opens the object in the live editor. Use it once you've found the problem and want to fix it - it does not modify anything by itself.
The two icons on the far right edge switch the right panel between Execution Details (the info icon) and Settings (the gear). The Settings view is where you can confirm whether Auditing was enabled for the object, which determines whether you see any runtime values at all.
What Is the Execution History Panel?
The left panel lists past runs of the object you're looking at, newest first. Each entry shows the date and time, how the run was triggered, the outcome, and the duration:
04 Sep 4:50 PM Test Via Console - Success • 130ms
Failed runs appear in red with a red status icon; successful ones carry a green tick.
The currently loaded execution is highlighted in the list, so you always know which run the middle and right panels are showing.
How Does the Execution History Filter Work?
The funnel opens a filter scoped to this object's runs only; it does not affect the main list.
Filtering the history does not change the middle or right panels. They stay on whichever run you last loaded, even if your filter excludes it.
What Is the Execution Details Panel?
The right panel holds the metadata for the run. The same fields appear for rules, workflows, and individual workflow nodes.
Execution ID
The full identifier, with a copy icon beside it
Copy it to search for every related record across both Audit Trail tabs
Message
The system's verdict on the run
Read this first. On failure it usually names the cause outright - nodeId not found, or error found in row_#2, error_parse_output_data_json: unsupported value: +Inf. Renders red when the run failed
Date & Time
When the run started
Correlating with an incident or a deploy
Event
How it was triggered
Confirms whether this was real traffic or your own test
Status
The outcome
Duration
How long the run took
A sudden jump points at a slow query or a timed-out call rather than at your logic
Mode
The environment
Branch
The Git branch, if Git is connected; a dash otherwise
Version
draft or a published version number
Check this when a fix appears not to have worked. A published version may still be serving traffic while you test a draft
Type
What ran, in internal spelling
Confirms which kind of execution you're looking at
Input Output
Two tabs - Input and Output - holding the payload that went in and the result that came back
The run's boundary conditions. If the output is wrong but the input was already wrong, the problem is upstream of this object
How Do the Three Panels Work Together?
The relationship is worth stating plainly:
Execution History selects which run you are looking at.
The middle region shows what happened inside that run - the grid, the tree, or the canvas.
Execution Details shows the verdict and metadata for that same run.
Changing the selection in Execution History updates both of the others. Clicking inside the middle region - a cell, a node - opens more detail without changing which run is loaded.
What Does a Rule Execution Look Like?
Decision Table, Simple Rule, and Rule Set executions all open into the shared three-panel screen described above - Execution History on the left, Execution Details on the right. What's in the middle depends on which one you ran.
This section covers that first, then what's specific to a Decision Table, then a Simple Rule, then a Rule Set on its own.
What Shows Up on Every Rule Execution?
View Input Attributes sits above the rule regardless of its type. If the logic looks correct but the result still isn't, the inputs are the next place to look.
Here you can see the table containing the values below:
Name
The parameter the rule expects
Type
Numeric, Date, List, Json, String - a type mismatch here explains a whole class of wrong results
Test Value
The saved test value, with an indented arrow beneath showing the value actually used in this run
Can be Null
Whether an empty value was permitted
Case Sensitive
Whether string comparison respected case - the usual cause of a string condition that "should have matched"
Is Optional
Whether the parameter could be omitted
This is where you catch a string arriving where a number was expected, or an optional field that came through empty and silently changed the outcome.
Where Do Executed Values Appear on a Condition?
Wherever a condition is shown, the value it actually tested against during this run appears directly beneath it, as an indented arrow underneath the configured side of the comparison:
Same for Decision Table as well. If you want to see the input parameter value used for a condition, then that will be visible below the condition key, like you can see here for the "Date". And if you want to see the value of the executed condition (i.e., individual cell value) then click any cell in the grid to open that condition inline.
Every part of the condition gets this treatment - the attribute being tested and each side of the comparison - so you can read what was actually compared against what, in place, without opening anything.
How Do I Tell Whether a Condition Matched?
A condition or group is tinted green to show that the row, or that condition, was successfully executed. If the row or the condition is showing a lighter, neutral tint, then that row wasn't executed. And then if the row is tinted red, then it was executed but failed.
How Are Post-Rule Actions Represented?
An action configured to run after the rule can succeed or fail independently of the rule's own result. Where an action has run, its status is shown with a dot: green if it fired successfully, red if it failed while the rule itself still succeeded.
That red state is what the Action Failed status in the list means - the decision was made correctly, but the thing that was supposed to happen as a result did not. If the rule returned the right value but nothing happened downstream, check the post-rule actions before anything else.
Both a Decision Table and a Simple Rule let you add post-rule actions; where the control to add one appears depends on the type - see below.
Rule Set
A Rule Set execution is presented as a list of its member rules, not as a grid or a tree. Your task on this screen is routing - identifying which member rule produced the result - before moving into that rule.
A Rule Policy control at the top of the list shows how the set was evaluated for this run - for example Evalute All.
Rules that matched are tinted green, giving you the same at-a-glance scan as a Decision Table's rows.
How Do I Identify Which Rule's Result Was Used?
Look for the row marked Result used. That is the member rule whose output the Rule Set returned. Every other row ran (depending on policy) but did not supply the answer.
How can I open a specific Rule used in RuleSet?
Clicking View Rule on any row opens that member rule's own full execution, stacked on top of the Rule Set view.
What you get is a complete rule execution in its own right - the member rule's grid or condition tree with its own executed values and matched-row indicators, and its own Execution Details panel with its own Execution ID, prefixed ruleInternal: to mark it as a rule that ran inside another rule.
From there you investigate it exactly as described above under Decision Table or Simple Rule, whichever it is.
Closing the stacked view returns you to the Rule Set.
What Should I Check If a Rule's Result Is Unexpected?
The checks that resolve problems fastest, for whichever type you're looking at:
Read the executed values under the conditions. If an input is already wrong, stop - the problem is upstream of the rule.
Find what actually matched by scanning the tint - the row on a Decision Table, or the path down to the leaf condition on a Simple Rule. On a Rule Set, find the row marked Result used.
If the wrong thing matched, open the specific condition or cell responsible and compare its configured value against its resolved value.
If nothing matched, a Decision Table returned its default and every row is tinted red - check whether that was intended. On a Rule Set, check whether the rule you expected to run is disabled, or whether the Rule Policy stopped evaluation early.
If the logic looks right, open View Input Attributes and check types, case sensitivity, and whether an optional field arrived empty.
If the result is right but nothing happened afterwards, check the post-rule actions - chips on a Decision Table, added per branch on a Simple Rule.
If there are no executed values anywhere, Auditing was off - see Auditing.
What Does a Workflow Execution Look Like?
A workflow execution opens as your node graph, with each node showing how it fared during this run.
How Is Node Execution Status Displayed?
Each node carries a status badge in its corner, a coloured border, and a status line beneath its name.
Green tick
Success with duration
The node completed normally
Red cross
Failed with duration
The node errored
Orange warning
Success with Failed actions
The node's own logic succeeded, but an action it fired failed
Gray
Not Executed
Node not executed, and no execution details available
Two additional markings appear on specific nodes:
Version chip (
Vdraft,V1.0) - Appears mainly on rule and workflow nodes, showing whether a draft or published version executed inside the workflow.
Pass/fail counters - on Loop nodes, in place of a single badge
What Happens When I Click a Node?
A wide detail panel opens, split into two halves.
What Does the Left Half Show?
The same fields as the run-level Execution Details, but scoped to this node: Message, Date & Time, Event, Status, Duration, Mode, Branch, Version, Type.
Two things to note:
Message at node level is usually more specific than the workflow-level message. Read it first.
Type shows the node's internal kind -
restApiNode,setVar,switch,decisionTable- confirming exactly what you clicked.Duration shows a dash for nodes that complete instantly.
If the node is inside a loop, an iteration selector appears beside the node name at the top of the panel.
If the node runs another Nected object(i.e., Rule or workflow), a View assets executions › button appears here, which will take you to the execution log of that object.
What Does the Right Half Show?
Two or three tabs, depending on the node type:
Input Params
The node's configuration as it was for this run, with each configured value showing its runtime-resolved value beneath
Output
What the node returned
Settings
The execution settings that applied during the run
Control nodes have only Input Params and Output.
What Is the Output Envelope?
Most nodes return the same wrapper:
error
Empty on success; carries the message on failure
executionTime
That node's own duration
output
The node's actual result
step
The node's position in the execution order
This gives you the core technique for workflow debugging: when a node behaves unexpectedly, read the Output of the node above it.
What Does Each Node Type Show?
What appears inside Input Params and Output depends on the node. Below is what each one gives you to investigate.
Rule Node
Input Params shows which rule was selected, the Run In Loop setting, and each input parameter with its configured token and its resolved value.
Output carries the rule's return payload.
View assets executions ›, on the left half of the panel, is the important control. It opens that rule's own complete execution - the annotated grid or condition tree, the matched row, the cell-level detail - scoped to this node's run within this workflow.
If the rule node sits inside a loop, select the iteration first, then open the rule - you will get that rule's evaluation for that single pass.
Set Variable Node
Input Params is a Key Name / Value table with one row per variable. Each row shows the configured expression and, beneath it, the value that expression resolved to during this run:
Switch Node
This node has only Input Params and Output - there is no Settings tab.
Input Params lists the branches in evaluation order: an IF, then any number of ELSE IF branches, then a Default - each showing its attribute, operator, and comparison value.
Output identifies the branch that actually executed:
The path value is the branch this run followed. When two runs of the same workflow behave completely differently, comparing this value between the two runs is usually the entire explanation.
Loop Node
A Loop node shows pass and fail counters instead of a single status badge, plus an iteration dropdown on the node itself listing every pass with its own outcome:
Selecting an iteration re-scopes the entire panel to that pass. Any node inside the loop then shows the values, message and status for that single iteration rather than an aggregate - so you go straight to the two failures in a batch of two hundred.
A Loop node can also fail as a whole, carrying a red badge itself. That indicates the loop construct errored rather than an individual pass.
What Does a Response Node Show?
Shows exactly what was returned to the caller, and carries an End Workflow toggle.
Open it when an API caller reports receiving nothing - this tells you what was actually sent.
What Does a Code Node Show?
Input shows the language and the code that ran; Output shows what it returned.
What Does an Action Node Show?
An outbound call fired as part of the workflow. A failure here is what produces Success with Failed actions on the parent node; the per-action results are on the Actions sub-tab of the node's Output.
What Does a Sleep Node Show?
A fixed delay. There is nothing to inspect beyond confirming that it ran and how long it took.
What Does a Connector Execution Look Like?
Connector runs are the one execution type with no replay. There is no builder to reopen, so clicking a connector row opens the Execution Details panel and nothing else.
There is no Execution History panel, no middle region, and no Input Output section.
The panel carries the standard fields, with:
An Execution ID prefixed
test_connector:A Message such as
successfully executed connector <name>Type shown as
connector
For a connector, the metadata is the record: whether the connection succeeded, how long it took, when it ran, and against which version. If a connector test failed, the Message is where the reason appears.
Filters
Audit Trail has three filtering interfaces. Two of them - on the Activity Logs and Execution Logs screens - share the same control and behave identically. The third, inside an open execution, is a different control with different rules.
Activity Logs / Execution Logs screens
Changes or runs across the workspace
Multi-select
Instant
Execution History, inside an open execution
Past runs of that one object
Single-select
Requires Apply
What Filters Are Available on Activity Logs and Execution Logs?
The filter row sits directly below the tabs on both screens: a search box, a set of dropdowns, and two date fields. Activity Logs has four dropdowns: Type, Event, Status, Mode. Execution Logs has five, the same four plus Source, and its Type, Event, and Status lists hold different values.
Search By ID or Name:
The Search By Id or Name box on Activity Logs and Execution Logs behaves identically on both screens.
What it searches
Both the object's name and the event ID.
Matching
Fuzzy match: searches for the value anywhere within the object name. For example, searching t1 finds an object named Dt1. It does not require an exact match or a prefix match.
Case
Insensitive. asd and ASD return identical results.
Related records
Also returns records connected to the match, not just the row whose name matched - for example, searching a rule set's name returns the rule set and the member rules that ran inside it.
To trace one event end to end: open any record, copy its ID, and paste it into the search box on either tab. Because search matches IDs, you get every row tied to that event, including the nested rows a run generated.
What Does the Type Filter Do?
Activity Logs filter changes based on the type of object that was modified. They include 19 options:
Rule Set, Simple Rule, Data Source, Connector, Global Variables, Decision Table, System API Key, Authorization, Cron, Workflow, API, Wait, Wait Multi, Resume, Webhook, Attribute Library, Attribute, Tag, Document
Execution Logs filter records based on what was executed. They include 6 options:
Simple Rule, Decision Table, Rule Set, Workflow, Cron, Test Suit.
What Does the Event Filter Do?
Activity Logs - seventeen options, covering two different kinds of thing:
Lifecycle events - someone changed something, Create · Update · Delete · Discard · Publish · Push · Pull · Sync · Role Update · Role Revoke
Run events - something executed: Test Via Console · Call Via API · Test Cron Via Console · Call Via Cron · Webhook · Call Via Delay · Test Via Delay
When auditing changes, tick only the lifecycle events - runs write far more rows than edits do, and leaving run events in buries the handful of changes you're looking for.
Execution Logs - filters by how the run was triggered. Six options:
Call Via API
Something called the object's endpoint - live production traffic.
Webhook
An external system pushed data in through a webhook trigger.
Call Via Cron
A schedule fired.
Test Via Console
Somebody pressed Test Run inside the editor.
Test Cron Via Console
Somebody fired a cron-scheduled object manually from the editor.
Testsuit
The run came from a test suite.
What Does the Status Filter Do?
Activity Logs - two options: Success · Error. Tick Error on its own to see every failure across the workspace.
Execution Logs - six options:
Success
The run completed.
Error
The run failed.
Running
Still executing right now.
Pending
Waiting on something - most often a Wait & Resume step that has not been resumed.
Trigger
The trigger fired, but no completed outcome is recorded against this row.
Action Failed
The logic succeeded but a post-rule action failed. The decision was made; the side effect did not land.
Tick Error and Action Failed together when hunting failures - they are genuinely different and neither implies the other, so filtering on Error alone will miss a run whose action failed.
What Does the Mode Filter Do?
Both screens offer Production · Staging, and both have a verified problem.
What Does the Source Filter Do?
Execution Logs only. Two options:
Internal - a console test, or one object calling another inside Nected
External - your own services calling the API from outside
This is the most reliable way to isolate genuine outside traffic, and the filter to reach for instead of Mode.
How Do the Start Date and End Date Filters Work?
Both main screens have Start Date / End Date; Execution History has the same pair under Date Range.
The fields are read-only — click one to open a calendar with month/year navigation, a Today shortcut, and a Time field. The bounds are timestamps, not whole days, and default to 00:00 on the day you pick. You don't need both: setting only a Start Date applies immediately as an open-ended "from this moment on."
What Filters Are Available in Execution History?
Where Do I Find It?
Open any execution from Execution Logs. The Execution History panel on the left lists past runs of that one object. A funnel icon at the top of that panel opens the Filter panel.
How Do I Apply and Clear These Filters?
Nothing is applied until you click Apply. Reset clears every field, including the pre-filled search - it's the only way to get back to the object's full history.
Filtering the history does not change what's shown in the middle and right panels - the replay and Execution Details stay on the run you already loaded, even if your filter excludes it. The filter narrows the list only.
An empty result reads No Execution Found, rather than the illustration shown on the main screens.
How Do Date Filters Behave?
Both main screens have Start Date / End Date; Execution History has the same pair under Date Range.
The fields are read-only - click one to open a calendar with month/year navigation, a Today shortcut, and a Time field. The bounds are timestamps, not whole days, and default to 00:00 on the day you pick. You don't need both: setting only a Start Date applies immediately as an open-ended "from this moment on."
The trap: setting Start Date and End Date to the same day returns nothing, since that asks for a zero-width window at midnight. To cover a whole day, set End Date to the next day, or set an explicit time in the picker.
Clearing: there's no clear button and no reset on the main screens - reloading the page is the only way to remove a date. Execution History's Reset clears its dates along with everything else.
Auditing
Every runtime value described in this document - the executed values under decision table conditions, the resolved query on a database node, the token resolutions on a Set Variable node, the Input & Output payloads on both Activity Log records and Execution Log replays - depends on a per-object setting called Auditing. It is off by default.
With Auditing off, Nected still records that the run happened, when, how long it took, and whether it succeeded. It does not record the values that passed through.
You can check whether it was enabled for the run you are looking at using the Settings icon on the far right edge of the execution screen. Enabling it, and the security considerations of recording live data are covered in the old Audit Trail doc.
Last updated