Workflow Executions
The Runs tab of the Workflows page (/workflows/runs) shows the history of every workflow evaluation triggered by scan events. Use it to verify that workflows are triggering correctly, review action results, and diagnose issues when workflows don't behave as expected.
Overview
Every time a scan event is processed, Tagnet evaluates it against your configured workflows. A workflow whose event conditions match the event produces an execution record, whether its actions then ran or its tag conditions matched no tags. A workflow whose event conditions do not match records nothing. This page lets you review those records.
From the Runs tab you can:
- Review the history of workflow evaluations
- See which workflows triggered, which didn't, and why
- Inspect action results and timing
- View the tags that were processed and filtered
- Open an analytics page with execution trends
Permissions
| Permission | What It Allows |
|---|---|
| View Workflows | Access the Workflow Executions page and view execution history |
Note: This is the same permission that gates Workflows and Message Templates. Movement Rules use their own View Movement Rules permission, though the built-in roles grant both together. Neither is granted to the Operator role by default. Creating and changing workflows needs Manage Workflows, which for the beta only the Admin role holds. See Users, Roles & Access Scopes.
Which runs you see
Each run belongs to the site of the reader whose scan event triggered it. A Shared workflow runs for every site's readers, but you see only the runs from the sites in your access scopes: on this page, in a run's detail, in the run count in the navigation, in the workflow's last run and latest failure, on the Home page's workflow activity, and in Tagnet AI's answers. Administrators see every run.
Runs recorded before this rule existed were assigned a site when Tagnet was upgraded, from the reader that triggered them. A run whose scan event had already been removed by retention keeps its workflow's site when the workflow belongs to one site. On a Shared workflow such a run has no site, and only administrators see it. Workflow activity counts from before the upgrade follow the same rule: a Shared workflow's older counts are visible to administrators only.
The Executions Grid
The list is server-paged for fast performance with a large execution history.
Search and Filters
The search bar matches by tag EPC or inventory item name. There is no separate workflow-name search; use the Workflow filter (multi-select) instead. Additional filters: Result, Conditions, Device, and an executed-date range. The Runs link on a lane of the Diagnostics tab opens this list with the Device filter set to that reader.
Columns
| Column | Description |
|---|---|
| Result | Overall outcome: Success, Partially Failed, Failed, or Not Executed (color-coded) |
| Workflow | The workflow that was evaluated (clickable link) |
| Conditions | Whether the tag conditions found tags after the event conditions matched: Met, No matching tags, or Not met (records from older releases) (color-coded) |
| Source | The device or device group that captured the triggering scan event. For a group-collected event, this shows the device group, since a multi-reader portal reads as one grouped source rather than being attributed to whichever reader happened to report first |
| Executed | When the execution occurred |
| Duration | Time elapsed from start to completion |
| Tags | Ratio of tags that matched the tag conditions to total source tags (e.g., "5/10") |
Every column can be shown or hidden from the column chooser on the grid header, and your choices are remembered between sessions.
Execution Results
| Result | Meaning |
|---|---|
| Success | Workflow triggered and all actions completed successfully |
| Partially Failed | Workflow triggered but one or more actions failed |
| Failed | Workflow triggered but actions could not complete |
| Not Executed | No tag in the scan event matched the tag conditions, so no action ran |
Execution Details
Click any row (or choose Details from the row actions menu) to open the execution's own page at a stable, shareable URL, with three tabs:
Overview Tab
Shows the execution overview:
- Source workflow: Which workflow was evaluated (clickable link to the workflow)
- Scan event: The originating scan event (clickable link)
- Timestamp: When the execution occurred
- Tag counts: Source tags and how many matched the tag conditions
- Status badges: Conditions and result
- Actions: Each action that ran, as a numbered step matching its position in the workflow's own action list, with its result, message, and timing
Each step's number and status chip take the color of its outcome: green for success (or a delivered HTTP Integration), blue for no effect (or a delivery still in progress), red for a failure, and amber for an abandoned delivery. A skipped step shows a hollow grey circle and a dimmed card, since a run condition not being met is normal, not a problem.
For an HTTP Integration (durable) action, the chip shows the queued delivery's actual outcome (Delivered, Delivering, Delivery failed, Dead-lettered, or Abandoned) once you can see deliveries and one exists, instead of the plain Queued status; see What "Queued" means in the Integration Outbox guide for the full breakdown, including what a viewer without delivery access sees instead.
Each card's footer line shows when the action ran, how long it took, and (when relevant) how many tags it affected. Hover the timestamp for the full date and time down to the millisecond. The icon buttons for additional detail sit at the right of that same line, depending on what the action produced:
| Button | Shows |
|---|---|
| Sent Request | Wire-format view of the request as sent (Send HTTP Request actions only): method, URL, headers with authentication values masked, and body up to 4,000 characters |
| Input Context | The data the action received when it ran, as JSON |
| Output Data | The data the action produced, as JSON |
| Result Data | Additional result detail, as JSON, when it differs from Output Data |
The JSON viewers (Input Context, Output Data, Result Data) pretty-print the stored value and expand any nested JSON strings, such as a response body captured as a string, so the structure is readable. Toggle Raw to see the exact stored value instead.
Tags Tab
A data grid showing all tags from the source scan event:
- Conditions: Whether each tag matched the workflow's tag conditions
- EPC: Tag identifier
- Inventory mapping: Whether the tag is mapped to an inventory item
- Zone, State and Direction: The tag's latest directionality event, shown only when the run's tags came from a Zebra ATR7000
- Motion indicator: Tag motion state (if available)
- Read count and RSSI: Signal data
The mapping shown here is what the reader saw: the scan record is never rewritten. A tag mapped by a workflow above this one in the run order, or by an earlier action in this run, still shows as unmapped here, while the Source Data tab shows the item it was mapped to.
Source Data Tab
The raw JSON payload of the source scan event, useful for debugging workflow conditions. This is the snapshot the workflow started from: tag and inventory data as it looked when this workflow began, which includes what the workflows above it in the run order did for the same scan event. It is also what the workflow's FOR conditions evaluated. If an action in this run changed that data (moved an item, updated a custom field, mapped a tag), later actions acted on the new values, not what's shown here. See Current Data vs Trigger Data in the Workflows guide.
Execution Analytics
Open the Analytics tab of the Workflows page to view execution trends and summary metrics.
Controls
- Time range: Select 1 hour, 6 hours, 24 hours, or 7 days
- Workflow filter: Multi-select to focus on specific workflows
- Refresh: Reload analytics data
Summary Cards
| Metric | Description |
|---|---|
| Total runs | Number of workflow evaluations in the time range |
| Conditions met | How many runs met the workflow's conditions |
| Average Duration | Mean execution time across all triggered workflows |
| Failed Actions | Number of individual action failures |
Charts
The page displays four time-series charts with data aggregated in 15-minute intervals. Statistics are aggregated after each bucket closes, so the most recent bucket can trail live activity by up to 15 minutes; a "Data through" caption shows how fresh the charts are.
- Run volume: Runs whose conditions were met and not met over time (a run where no tag matched the tag conditions counts as not met)
- Action Results: Success, No Effect, Failed, and Skipped action counts
- Average Duration: Execution duration trends in milliseconds
- Tag Funnel: Source tags vs. matched tags, showing how many tags meet the workflow's tag conditions
Best Practices
- Review failed executions: Check the Tags and Source Data tabs to understand why actions failed.
- Use Execution Analytics for trends: The time-series charts help you spot patterns like increasing failure rates or processing slowdowns.
- Filter by workflow: When investigating a specific workflow, use the Workflow filter to focus on just that workflow's executions.
- Search by tag or item: If you know the EPC or item name involved, search for it directly instead of scrolling through the list.
- Check the tag funnel: If a workflow is triggering but producing "No Effect" results, the tag funnel chart on Execution Analytics can reveal whether tags are being excluded by the tag conditions before reaching actions.