> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/service-automation/run-a-local-work-item-and-inspect-its-logs.md).
# Run a local Work Item and inspect its logs
Run an isolated Work Item and inspect its action log before testing service orchestration.
Test a small Work Item on its own before using it to investigate service orchestration. This example ran one isolated Execute Work Item directly through **Run Hyper Flow**. It demonstrates a successful manual Work Item run; it does not demonstrate a successful deployment, webhook request, or Service Case.
### Prepare a harmless example
Use a separate test Work Item in an authorized non-production environment. Keep the logic local:
{% code collapsedlinecount="10" %}
```mermaid
flowchart LR
A[Start] --> B["String Assign docs-validation-ok → docs_result"]
B --> C[Stop]
```
{% endcode %}
The inspected definition uses a string variable named `docs_result` and assigns the literal `docs-validation-ok`. It contains no external application connection, AI call, email, or schedule. The released version is **Active v1.0.0**.
The earlier v1.0.0 package reports no input variables, no output and noData. For a consuming Work Item, mark the required variables Use as Work Item Input so deployment requests them. To return a value to following Work Items, assign the producing variable to the Stop body, release the item and use that release in the intended service version.
### Run and inspect
1. Open the isolated Work Item in its Hyper Flow editor.
2. Verify the intended name, version, and local actions before running it.
3. Select **Run Hyper Flow** once.
4. Read the **Manual Trigger** completion message and **Logs Summary**.
5. Open **View All Logs** and check the actions between the start and end records.
In this example, the interface reported **Completed successfully!** and **The operation was successfully completed!**
| Observed field | Value |
| ---------------------- | --------------------------------------------------- |
| Work Item | Docs V2 - Local validation - 20261012 |
| Version displayed | Active v1.0.0 |
| Trigger | Manual Trigger |
| Number of Transactions | 1 |
| Total Time Elapsed | 0.03 sec |
| Started / ended | 12 October 2026, 13:15:40; time zone not shown |
| All Logs | Autom started → String - Assign, INFO → Autom ended |
*Figure 1. The single action appears in the completed run's log. This view does not display the final value of the local variable.*
The transaction count is the field shown in this execution summary. Do not interpret it as a billing measure or use the elapsed time of this one local action as a performance benchmark.
## Follow the newer request-intake example into its action data
The request-intake Work Item described in [Work Items](/userguide/service-automation/create-work-items-and-pin-released-versions.md) adds a practical data-inspection step. Its service execution is separate from the earlier manual run above.
1. Open **Docs - Prepare request summary - 20261013**, choose its **Active v1.0.1** release and select **Run Hyper Flow**.
2. When the run completes, open **View All Logs** and select the **Stop & Return** action's information.
3. Select **Fetch Input Output** to inspect the action's actual data instead of inferring a value from the canvas.
4. Compare `responseData` with `REQ-DEMO-001 | VPN access | Maya Chen` and inspect the Result input separately from the HTTP response settings.
The direct v1.0.1 run on **13 October 2026 at 08:56:14**, as displayed in the browser, reported successful completion. The fetched input shows `result: true`, the exact sample response data, code `200` and `text/plain`.
The earlier service test SC-3 used Work Item v1.0.0, not this direct-run version, and its deployment reported noData. The direct v1.0.1 test confirms the Stop body contains the sample summary. Passing that output into a following Work Item requires selecting it in the new package’s deployment binding and inspecting the consuming run.
### What this result establishes
The manual trigger completed and logged the intended String Assign action. The final `docs_result` value was **not inspected**, and the Work Item did not expose an output. The evidence therefore supports the completion of this direct run, not a separately verified value or business outcome.
The [Enterprise deployment example](/userguide/service-automation/create-an-enterprise-service-deployment-draft.md) follows the separate service path: a POST to its development webhook produced a Service Case with the selected version, package and phase journey. A direct Work Item run and a service run answer different questions. Inspect the service Case as well as the Work Item log when checking the complete path. The example Prove step assigns a fixed string; use a check of the actual Execute result before treating it as independent outcome verification.
