Skip to main content
Track workflow execution, review results, and debug issues. Every workflow run is logged with detailed step-by-step information.

​
Who can view run records

Full run history and step details require View workflow runs on the team that owns the workflow. This permission applies to the team’s runs, not just runs you started. Custom roles, roles inherited through groups, and customized built-in roles can change these defaults. Check the effective View workflow runs permission; a role name alone might not describe a user’s access. See Permissions. On an ordinary team, an organization admin with a team membership uses the effective team role permissions; the organization-admin permission set isn’t added to them. Organization admins retain administrative authority on the organization management workspace. Some role choices, including Drafter, Application Builder, and Restricted, are available only when enabled for your organization. An Agent can read run details without having permission to browse workflow definitions. Seeing a ticket or a summarized workflow status also doesn’t necessarily grant access to full run records. For a workflow shared by another team, the requesting team’s result view uses separate shared-workflow permissions and checks the caller’s access to the shared workflow. It shows the shared run’s result rather than granting access to the owning team’s full step history.
Run-record access uses Serval permissions. It doesn’t recheck each viewer’s access to the source systems whose data appears in the run. Consider the audience for run records when choosing which data a workflow processes and retains.

​
Viewing Workflow Runs

Access run history for any workflow:
1

Navigate to the workflow

Go to Workflows and select the workflow you want to review
2

Open the Runs tab

Click the Runs tab to see execution history
3

Browse run history

View all runs sorted by date, with status indicators for each
4

Click a run for details

Select any run to see step-by-step execution details

​
Understanding Run Status

Each workflow run has a status indicating its current state:

​
Run Details

Click on any run to see detailed execution information:

​
Run summary

  • Started at - When the run began
  • Completed at - When the run finished (or failed)
  • Duration - Total execution time
  • Triggered by - Who or what initiated the run
  • Status - Overall result

​
Step-by-step breakdown

Each workflow step is logged with:
  • Step name - What action was performed
  • Status - Success, failure, or skipped
  • Duration - How long the step took
  • Input - What data was passed to the step
  • Output - What the step returned
  • Error - Error message if the step failed
Use the step-by-step breakdown to identify exactly where issues occurred. Failed steps show the specific error that caused the failure.

​
Debugging Failed Runs

When a workflow fails, follow these steps to diagnose and fix the issue:
1

Identify the failed step

Open the run details and find the step marked as failed
2

Review the error message

Check the error details for:
  • API errors from connected applications
  • Invalid input values
  • Permission or authentication issues
  • Network or timeout errors
3

Check the inputs

Verify the inputs provided were valid:
  • Correct format (email, date, etc.)
  • Valid values (existing users, resources, etc.)
  • Required fields were populated
4

Review application status

Check if the target application is:
  • Available and responding
  • Properly connected to Serval
  • Permissions are still valid
5

Re-run or fix and retry

Either:
  • Re-run with corrected inputs
  • Fix the workflow logic and publish a new version
  • Contact support if the issue persists

​
Common failure causes

Symptom: “Unauthorized” or “Authentication failed” errorsCause: API credentials expired or were revokedFix: Reconnect the application in Serval’s integrations settings
Symptom: “Resource not found” or “User does not exist” errorsCause: The target resource (user, group, repo, etc.) doesn’t existFix: Verify the input values are correct and the resource exists
Symptom: “Forbidden” or “Insufficient permissions” errorsCause: Serval’s integration lacks permission for the requested actionFix: Update the integration’s permissions in the connected application
Symptom: “Rate limit exceeded” or “Too many requests” errorsCause: Too many API calls to the application in a short periodFix: Wait and retry, or spread out workflow executions
Symptom: “Timeout” or “Request took too long” errorsCause: The target application took too long to respondFix: Retry the run, or check if the application is experiencing issues

​
Filtering and Searching Runs

For workflows with many runs, use filters in the run-history header to find specific executions:
  • Status - Show only runs in the statuses you pick. Use the is / is not operator to include or exclude specific statuses (for example, Completed, Failed, or Running).
  • Date started - Filter to runs that started within a date window.
  • Date completed - Filter to runs that finished within a date window.
Filters combine, and run numbers stay consistent while a filter is applied, so a run keeps the same number whether or not the list is filtered.

​
Scheduled Workflow Runs

For scheduled workflows, the Runs tab shows:
  • All scheduled executions that have occurred
  • The next scheduled run time
  • Whether scheduled runs are succeeding consistently
If a scheduled workflow consistently fails, it will keep trying at each scheduled time. Review and fix failures promptly to avoid repeated errors.

​
Exporting Run Data

Export workflow run history for reporting or compliance:
  1. Navigate to the workflow’s Runs tab
  2. Apply any filters needed
  3. Click Export or Download
  4. Choose your format (CSV, JSON)
Exports include:
  • Run timestamps
  • Status
  • Duration
  • Who triggered the run
  • Input values
  • Success/failure details

​
Best Practices

Monitor regularly

Check run history weekly to catch issues before they become problems

Set up alerts

Create a workflow that notifies you when other workflows fail

Review scheduled runs

Ensure scheduled workflows are running successfully on their expected cadence

Clean up old workflows

Disable or delete workflows that consistently fail or are no longer needed