Execution Logs
Execution logs record each run of an OpenLink integration flow. In the log page, administrators can review trigger results, search by trace or business data, filter by status, inspect execution details, open related local records, and use payload snapshots to troubleshoot mapping, target execution, callbacks, or script behavior.
Open Integration Flow Config from the selected OpenLink, select a flow, then use View execution logs to enter this page.
Log List
The page shows execution records for the selected flow only.
| Area | Description |
|---|---|
| Back | Returns to Integration Flow Config |
| Search Logs | Searches log ID, Trace ID, business data, trigger mode, status, time, duration, and related record identifiers |
| Status Filter | Filters logs by all results, succeeded, failed, running, or queued |
| Refresh | Reloads the current log list |
| Log Table | Shows execution records and provides detail and business data actions |
| Pagination | Switches pages and adjusts page size |
Use the log list after manual testing, webhook calls, poll runs, or push events to confirm whether the flow has run as expected.
Table Columns
| Column | Description |
|---|---|
| Log ID | Unique ID of the execution log |
| Trace ID | Trace identifier used to correlate one execution across runtime processing |
| Business Data | Business-facing label for the processed record when available |
| Trigger Mode | How the flow was triggered, such as manual, webhook, poll, or push |
| Status | Current execution result: queued, running, succeeded, or failed |
| Started At | Time when execution started |
| Ended At | Time when execution ended |
| Duration | Execution duration in milliseconds when available |
| Actions | Opens log details or opens related business data when a local record can be resolved |
If a log has local form and local record information, the business data action opens the related Soln form record in a new tab.
Statuses
| Status | Meaning |
|---|---|
| Queued | The execution has been accepted but has not started processing yet. For an outbound push flow using same-record sequential execution, it can be waiting for an earlier execution of the same record |
| Running | The execution is currently processing |
| Succeeded | The execution completed successfully |
| Failed | The execution ended with an error |
Use the status filter to focus on failed runs during troubleshooting, or running and queued runs when checking recent activity. A queued record does not mean the entire flow is blocked: different source records can still run concurrently. When the same-record sequential strategy applies, the next execution is released after the earlier execution succeeds, fails, is cancelled, or exhausts its retries.
Log Details
Open a log detail drawer from the table action.
The drawer is divided into basic information, execution overview, and execution details.
| Section | Description |
|---|---|
| Basic Info | Shows log ID, Trace ID, business data, trigger mode, status, start time, end time, and duration |
| Execution Overview | Shows the saved flow graph and the path recorded for this execution |
| Execution Details | Shows local record information, error information, and available JSON payload snapshots |
The business data value in the drawer can also open the related local form record when the log contains enough local record information.
Execution Path
The execution overview renders the graph snapshot attached to the log. Nodes and connections recorded in executionPath are highlighted so you can see the branch route actually taken by this run.
| Display | Meaning |
|---|---|
| Highlighted connection | The execution passed through this connection. A highlighted connection is animated while the log is running |
| Highlighted node | The execution reached this node. It displays the current overall execution status |
| Not run | The node was not part of the recorded path, for example the unselected side of a branch |
| Dashed connection | The connection exists in the saved graph but was not part of the recorded path |
Use the path first to locate the last reached node and confirm whether a branch selected the expected matched or unmatched route. Then use the payload snapshots below it to inspect source data, transformed data, target output, callback data, or the recorded runtime context.
Payload Snapshots
Execution details may include JSON snapshots. Only sections with data are shown.
| Payload Section | Description |
|---|---|
| Error Detail | Structured error information when execution fails |
| Input Payload | Original payload received by the flow |
| Transformed Data | Data generated by transform mapping |
| Child Tables | Child table output generated during mapping |
| Created Record | Local record result when the target creates a Soln form record |
| Script Result | Studio script execution result when the target calls a script |
| Applied Mappings | Field mappings applied during transformation |
| Raw Output | Full output payload captured by the flow execution |
| Context Snapshot | Runtime context captured during execution |
Each JSON panel can be copied. Use these snapshots when comparing external payloads with OpenLink external fields, field mapping, target action settings, or Studio script input.
Common Checks
When a flow does not produce the expected result, check the log in this order:
- Confirm the latest run exists in the list
- Check the status filter is not hiding the run
- Open the failed or unexpected log
- Confirm the trigger mode and input payload match the test request or scheduled run
- Check transform mapping count, child table mapping count, and transformed data
- Check target execution for created record, matched record, script result, or error message
- Check callback status when the external side expects an async response
- Open the related local record when the log provides business data
- Return to the flow design canvas to adjust nodes or mapping, then publish and test again
Recommended Workflow
For testing or troubleshooting a flow, use this sequence:
- Make sure the flow has a published version
- Enable the flow from Integration Flow Config when the trigger mode requires an active flow
- Trigger the flow manually, through webhook, by poll schedule, or by push event
- Open Execution Logs from the flow list
- Refresh the list and locate the latest run by time, Trace ID, or business data
- Open the detail drawer and review the execution path
- Use payload snapshots to identify whether the issue is in source data, transform mapping, target execution, or callback delivery
- Adjust the flow design, publish again, and retest