Overview

Execution Logs in the Integrations section give administrators a searchable history of integration activity. They help you investigate whether an external API call, connector action, or knowledge-management sync succeeded or failed — and provide the request and response details needed to troubleshoot the issue.

Instead of relying only on alerts, use Execution Logs to investigate individual incidents, validate a recent change, trace a workflow failure, or understand recurring integration errors.

Execution Logs are available under Integrations → Execution logs on the dashboard.

How Execution Logs Work

Whenever a supported integration, connector action, or KM connector sync makes an API call, the system records execution information such as:

• When the call started
• The request URL and HTTP method
• The returned status code
• Whether the execution succeeded or failed
• How long the call took
• Context about the connector, workflow, or sync where available
• The request body and response body

You can narrow the log history using filters, search for a known identifier or value, and open a log entry to inspect its full details.

Execution Logs are grouped into three categories so you can focus on the source of the activity you are investigating.

Execution Log Categories

Custom

The Custom tab shows API calls made through custom integrations. Use it to investigate calls to external systems that are configured directly for your bot.

Typical examples include:

• A custom Workday API call returning an authentication error
• A ServiceNow endpoint returning an unexpected response
• A user-specific integration request failing during an employee transaction

The table includes:

• Employee/User ID: the user associated with the request, when available
• Route: the internal route that handled the request
• Request URL: the external API endpoint called
• Status code: the HTTP response code returned by the external service
• Initiated on: when the call began
• Time elapsed: how long the request took to complete
• Status: whether the call succeeded or failed

Connectors

The Connectors tab shows calls made by connector-based actions, including actions run from workflows.

Use this tab when you need to determine whether a configured connector action — such as creating a ticket, fetching employee data, or submitting a request — completed successfully.

The table includes:

• App name: the external application, such as Workday or ServiceNow
• Action: the connector action that was executed
• Request URL: the endpoint called
• Connector name: the configured connection used for the call
• Workflow Application Identifier: the workflow application associated with the execution
• Workflow node name: the workflow step that executed the action
• Type of execution: whether the call was a run-time execution, test action, test connection, data fetch, or authentication activity
• Reference ID: an identifier that can help trace the related workflow run
• Status code
• Initiated on
• Time elapsed
• Status

KM Connectors

The KM connectors tab shows sync-related API calls for knowledge-management connectors.

Use this tab to investigate scheduled or manually initiated knowledge syncs, including whether a specific sync completed successfully and which connector or connection was involved.

The table includes:

• Connector: the KM connector responsible for the sync
• Connection name: the configured connection used by the sync
• Sync ID: the identifier for the specific sync run
• Sync trigger type: how the sync started, such as scheduled, manual, or on demand
• HTTP method
• Request URL
• Status code
• Request timestamp
• Status

For KM connectors, a successful response is identified by a 2xx HTTP status code. Other response codes are shown as failed.

Searching, Filtering, and Reviewing Logs

Each tab provides a log table with:

• Search: search across available log information, including identifiers, request or response content, request URLs, and relevant application or sync details.
• Filters: limit results to a specific time period, status, endpoint, connector, action, or other relevant fields.
• Sorting: sort executions by their timestamp.
• Pagination: move through large result sets and choose how many rows to display per page.
• Manage columns: customise which available columns are visible in the table.

Start with a narrow date range and failed executions when investigating a live incident. Then add a connector, action, URL, workflow, or sync identifier to isolate the relevant calls.

Common Filters

The available filters vary by tab.

Filters for Custom and Connector Logs

Both Custom and Connectors support the following common filters:

• Start Date / End Date: show calls initiated within a selected date range. Future dates cannot be selected.
• Request Method: filter by GET, POST, PUT, PATCH, or DELETE.
• Request URL: filter by a specific external endpoint.
• Request Base URL/Domain: focus on a particular external system or tenant.
• Request URL Path Name: focus on a specific part of an API endpoint.
• Response Status Code: filter by a status code such as 200, 401, 404, 408, 429, 500, or 504.
• Failed actions: show only executions that failed.

Advanced filters are also available for internal request context, including the incoming method, URL, route, and path used by the platform or middleware.

Additional Filters for Custom Logs

The Custom tab also supports:

• Employee ID: identify calls initiated for a specific employee or user.

Additional Filters for Connector Logs

The Connectors tab includes workflow and connector-specific filters:

• Third-party Application: select one or more external applications.
• Connector Name: select one or more configured connectors for the chosen application.
• Action: select one or more connector actions for the chosen application.
• Type of execution: distinguish production run-time activity from testing, authentication, data fetches, or connection tests.
• Workflow Application Identifier: isolate executions from a particular workflow application.
• Workflow node name: isolate calls from a specific step in a workflow.
• Workflow reference ID: find the connector calls associated with a particular run-time request.
• Workflow item ID: investigate a specific workflow item.
• AIC run ID: find calls associated with a workflow triggered from AIC, when applicable.

Filters for KM Connector Logs

The KM connectors tab supports:

• Start Date / End Date: show sync calls within a selected date range.
• Connector: choose one or more KM connectors.
• Connection Name: find a connection by any part of its name.
• Sync ID: find a specific sync run.
• Sync Trigger Type: filter by how the sync was started.
• HTTP Method: filter by GET, POST, PUT, PATCH, or DELETE.
• Status: show successful or failed calls.
• Status Code: filter by a specific HTTP status code.

Viewing Execution Details

Select any row to open its details in a side panel.

The panel provides the full available information for that execution, including the fields shown in the table and additional troubleshooting context.

Depending on the log category, details can include:

• Application, action, connector, workflow, or sync information
• Request URL, status code, timestamp, and elapsed time
• Success or failure status
• IP address for Custom and Connector logs, when available
• Metadata captured for the execution
• Request body
• Response body

Structured JSON request and response content is displayed in an easy-to-read format. Non-JSON content can also be reviewed and copied where available.

For Connector logs, execution source values are displayed in business-friendly terms, such as Run-time Execution and Test Action.

Troubleshooting a Failed Workflow Connector Action

Use this workflow when an action in a live workflow appears to have failed.

1. Go to Integrations → Execution logs.
2. Select the Connectors tab.
3. Set a date range that covers the time when the issue occurred.
4. Set Failed actions to show only unsuccessful calls.
5. Select the relevant Third-party Application — for example, Workday.
6. Optionally select the specific Connector Name and Action.
7. If the issue is limited to one workflow, use Workflow Application Identifier or Workflow node name to narrow the results.
8. Open the failed row.
9. Review the status code, elapsed time, metadata, request body, and response body.
10. Use the workflow reference ID, workflow item ID, or AIC run ID to trace related executions when available.

Example: Investigating a Workday Time-Off Failure

Suppose employees report that time-off submissions are failing.

1. Open Execution logs → Connectors.
2. Select a relevant date range.
3. Set Third-party Application to Workday.
4. Set Action to the action used for time-off submissions.
5. Set Type of execution to Run-time Execution to exclude Studio testing activity.
6. Enable Failed actions.
7. Open a failed record and review its response status and response body.

A 401 response may indicate an authentication or credential issue. A 4xx response may indicate an invalid request or permission problem. A 5xx response may indicate an issue with the external system or service availability.

Troubleshooting a Failed KM Connector Sync

Use this workflow when a knowledge source has not synced as expected.

1. Go to Integrations → Execution logs.
2. Select the KM connectors tab.
3. Choose the relevant date range.
4. Filter by Connector or Connection Name.
5. Set Status to Failed.
6. If you have it, enter the exact Sync ID.
7. Open the failed log entry.
8. Review the request URL, status code, request body, response body, and associated metadata.

Use Sync Trigger Type to distinguish an issue in a scheduled sync from one encountered during a manual or on-demand sync.

Understanding Status and Response Codes

The Status column simplifies the outcome of an execution:

• Success: the call completed successfully.
• Failed: the call did not complete successfully.

The response status code provides more detail:

• 2xx: the external service accepted and completed the request successfully.
• 401 / 403: authentication or access permissions may be invalid.
• 404: the requested endpoint or resource may not exist.
• 408 / 504: the request timed out or the external service did not respond in time.
• 429: the external service may be rate limiting requests.
• 5xx: the external service or a related gateway encountered an error.

The response body often provides the clearest explanation of why a failed request was rejected.

Log Retention

Execution Logs are retained for a limited period:

• Successful execution logs: retained for 10 days from the execution time.
• Failed execution logs: retained for 90 days from the execution time.

When investigating an older incident, keep these retention periods in mind. Capture relevant request and response details before the applicable retention window expires.

Permissions and Visibility

Access to Execution Logs is controlled by bot-level permissions and company settings.

• The Execution logs tab is visible only to users who have the relevant Integrations execution-log permission.
• Access to the log data itself is restricted to authorised administrator roles.
• Your organization must permit visibility of third-party logs for users to review them.

If you do not see the Execution Logs tab or receive an access message, contact your platform administrator or support team.

Best Practices

• Start with failures: when troubleshooting, filter to failed actions first and then narrow by date, connector, URL, or workflow.
• Separate testing from production: on the Connectors tab, use Type of execution to focus on run-time activity and avoid confusion with tests or connection checks.
• Use workflow identifiers for end-to-end investigation: reference IDs and workflow item IDs can help connect an external API failure to the workflow transaction that triggered it.
• Check both request and response content: request bodies help confirm what was sent; response bodies often explain why the external system rejected it.
• Use KM sync IDs for precise follow-up: when a knowledge sync fails, the Sync ID is the fastest way to locate its individual calls.
• Investigate recurring failures with Alerts: use Execution Logs for diagnosis and create an Alert rule when the same failure pattern needs proactive monitoring.
• Act within the retention window: failed logs remain available longer than successful ones, but capture evidence promptly for important incidents.