> For the complete documentation index, see [llms.txt](https://docs.nected.ai/nected-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nected.ai/nected-docs/audit/audit-trail.md). # 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?

Column	What it holds
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**](#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.

Field	What it tells you
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:

How Do I Read the ID?

For a change made by a person, the ID is a plain UUID. For a run, the ID is a compound, colon-separated string whose prefix tells you what ran and how: | Prefix | What it means | | ------------------- | ----------------------------------------------------------------- | | `test_rule:` | A rule tested from the console | | `test_workflow:` | A workflow tested from the console | | `test_connector:` | A connector tested from the console | | `ruleInternal:` | A rule that ran inside another rule - typically a rule set member | | `internal-rule-wf:` | A rule that ran as a node inside a workflow | | `condition-` | A single condition evaluation inside a rule | | `action:` | An action fired by a rule | | `delayWorkflow:` | A workflow involving a wait or delay step | Copy the ID into the search box on either tab to pull up every record connected to that event.

#### 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**](#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: ``` Ruleset → the rule set that was run Decisiontable → a member rule inside it Condition → a single condition that rule evaluated ``` Which tables appear tells you where you are in that chain: | Position | Shows | | --------------------------------------------------------------- | ----------------------- | | **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](https://docs.nected.ai/nected-docs/audit/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:

Column	What it shows	What it's for
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 `Error` and `Action Failed` together under Status** when hunting failures. They are different outcomes, and a run whose post-rule action failed still reports overall success - filtering on `Error` alone hides it. * **Use `Source`, not `Mode`, 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**](#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: | Type in the list | What opens | | ---------------- | ------------------------------------------------- | | `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.

| Region | What it is | | --------------- | ------------------------------------------------------------- | | **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 Do I Move Between Executions?

Simply just **click any entry** to load that run into the middle and right panels. The screen stays where it is; only the data changes. This is the most useful comparison technique available: load a run that failed, then load one that succeeded, and read the same grid or canvas twice. The difference between the two is usually the problem.

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.

Field	What it tells you	When it matters
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: | Column | What it tells you during debugging | | ------------------ | ----------------------------------------------------------------------------------------------------------- | | **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](/nected-docs/rules/rule-types/decisiontable.md) 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: 1. **Read the executed values under the conditions.** If an input is already wrong, stop - the problem is upstream of the rule. 2. **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**. 3. **If the wrong thing matched**, open the specific condition or cell responsible and compare its configured value against its resolved value. 4. **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. 5. **If the logic looks right**, open **View Input Attributes** and check types, case sensitivity, and whether an optional field arrived empty. 6. **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. 7. **If there are no executed values anywhere**, Auditing was off - see [**Auditing**](#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. | Badge | Status line | What it means | | -------------- | ----------------------------- | ------------------------------------------------------------- | | 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](/nected-docs/workflow/add-node/control-nodes/loop-node.md), 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: | Tab | What it holds | | ---------------- | ---------------------------------------------------------------------------------------------------------------------- | | **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](/nected-docs/workflow/add-node/control-nodes.md) have only Input Params and Output. **What Is the Output Envelope?** Most nodes return the same wrapper: ```json { "error": "", "executionTime": "598ms", "output": { ... }, "step": 7 } ``` | Field | What it tells you | | --------------- | ------------------------------------------------ | | `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.

Trigger Node

Shows which trigger fired the run - **API** or **Webhook** - and the payload that started it. **Every other node's input traces back to this one**, so when data looks wrong throughout the workflow, open the trigger first to establish whether the workflow was handed bad data to begin with.

REST API Node

**Input Params** show the request as configured: the Integration, the Method, the Base URL, the Authentication, the URL Path, and optional Headers and Query Parameters. **Output** holds the response in the standard envelope, with `output.Body` for the response body, `output.Headers` for the response headers, and `output.StatusCode`. These nodes also carry **their own Version** in the left summary.

Database Node

**Input Params** shows the integration, the specific connection, the action, and - the field that resolves most database problems - **both versions of the query**: the one configured with placeholders and the one that was actually executed with values substituted in.

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: ```json { "error": "", "executionTime": "0ns", "output": { "path": "Path3" }, "step": 7 } ```

**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 ` * **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. | Where | What it filters | Selection | Applying | | ----------------------------------------------- | ------------------------------------ | ------------- | ------------------ | | **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.

Behaviour	Detail
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:

Option	What it means
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:

Option	What it means
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.

{% hint style="info" %} This filter only ever searches the runs of the object you currently have open - it does not affect the Audit Trail lists. {% endhint %}

Why Is It Already Filtered When I Open It?

When you open an execution, the Execution History panel shows **only the run you clicked**, because the filter's search field is pre-filled with that execution's ID. The funnel already carries a blue dot to show that a filter is active. **Click Reset to see the object's full run history.** In testing, a decision table that appeared to have one run showed three the moment Reset was clicked, including a run triggered from inside a rule set. If you're wondering why a rule only has one execution, this is the answer.

How Does Search by Execution ID, Name, and Version Work?

Wider scope than the main screens: the placeholder reads **"Search by Execution ID, Name and version"**, and version is genuinely searchable - entering `draft` returns runs that executed a draft version. Unlike the main screens, typing here does nothing until you click **Apply**.

What Are the Status Options?

Six options, single-select: Success · Error · Trigger · Running · Pending · Action Failed.

What Does the Trigger Type Filter Do?

Six options, single-select: API · Webhook · Testsuit · Test Via Console · Cron · Test Cron Via Console. These map one-to-one to the **Event** options on Execution Logs, just with shorter labels - `Call Via API` becomes `API`, `Call Via Cron` becomes `Cron`.

How Does the Date Range Filter Work?

A **Start Date** and **End Date** field, behaving as described in [Date filtering](#how-do-date-filters-behave).

#### 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. {% hint style="info" %} **Auditing is not retroactive.** Enabling it records future runs only - a run that already happened without it stays that way. To investigate an intermittent failure, enable Auditing on that object and wait for the problem to recur. {% endhint %} 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](/nected-docs/audit/audit-trail/audit-trail-old-ui.md).