Integration Sources

An integration source is a configured connection to one external system instance — for example, your company's Jira Cloud workspace or your GitHub organisation. Once a source is created, project members can use it to link test objects to issues in that system.

Supported providers

TestOrchestrator supports the following external systems out of the box, plus a Custom Tracker option for any other system.

Provider Typical key format Notes
Jira Cloud PROJ-123 Project key + numeric issue number
GitHub Issues #123 Repository issue number
Azure DevOps 123 Numeric work item ID
Linear TEAM-123 Team identifier + issue number
GitLab Issues #123 Project issue number
Custom Tracker Configurable Use a key pattern to validate any format

Creating a source

Navigate to Admin → External References → Sources and click Add Source. The editor opens with three tabs.

SOURCE tab

The SOURCE tab defines the core identity of the connection.

  • Provider — choose the external system (Jira Cloud, GitHub Issues, Azure DevOps, Linear, GitLab Issues, or Custom Tracker).
  • Display name — the label your team sees when selecting a source to link against (e.g., Our Jira, GitHub Issues). Choose something that distinguishes this instance from others you may add later.
  • Base URL — the root URL of the external system instance (e.g., https://yourcompany.atlassian.net for Jira Cloud). Used to construct issue links and API calls.
  • Authentication type — how TestOrchestrator authenticates with the external system. See Authentication types below.
  • Issue URL template — optional. A URL pattern for opening an issue directly in the external system. Uses {baseUrl} and {key} placeholders (e.g., {baseUrl}/browse/{key} for Jira).
  • Create URL template — optional. A URL pattern for creating a new issue in the external system. Uses the same placeholders.
  • Key pattern — optional. A regular expression that validates issue keys entered by team members before saving the link (e.g., ^[A-Z]+-\d+$ for Jira). Prevents typos from creating invalid references.
  • Enabled — controls whether this source is available for use in projects. You can disable it at any time without deleting it.

URL template placeholders: Use {baseUrl} for the base URL you entered (without a trailing slash) and {key} for the issue key the user enters. For example, {baseUrl}/browse/{key} on a Jira source with base URL https://yourcompany.atlassian.net produces https://yourcompany.atlassian.net/browse/PROJ-123.

CAPABILITIES tab

Capabilities control what TestOrchestrator is permitted to do when communicating with this source. Each capability can be toggled independently.

Capability What it enables
Read issue details Fetch and cache the external issue's current status and assignee — displayed alongside the link in TestOrchestrator.
Create issues Show a shortcut button that opens the external system's new-issue form (uses the Create URL template). Requires a Create URL template to be configured on the source.
Add comments Post comments to external issues from within TestOrchestrator. Coming in a future release.
Process webhooks Accept inbound webhook events from the external system to trigger automatic data refreshes. Coming in a future release.

Add comments and Process webhooks are coming in a future release. You can enable these flags when configuring a source, but they are not yet active.

PROJECTS tab

The PROJECTS tab determines which projects can use this source when adding external references.

  • All projects — the source is available to every project in the workspace, including projects created in the future.
  • Specific projects — only the projects you select can use this source. At least one project must be selected when this option is chosen.

You can change the project assignment at any time by editing the source.

Authentication types

The authentication type determines how TestOrchestrator identifies itself when calling the external system's API.

Auth type When to use
API Token Most common. Used with Jira Cloud (email + API token), GitHub (personal access token), Linear, and GitLab. Credentials are stored encrypted and never exposed to end users.
OAuth 2.0 For systems that issue bearer tokens or access tokens via an OAuth 2.0 flow. Provide the access token directly.
Basic Auth Username and password pair. Use only when the external system does not support token-based auth.
None No authentication. Suitable for public systems or internal systems that do not require credentials.

The fields displayed under auth configuration change automatically based on the auth type and provider you select. Fill in all required fields — credentials are stored securely and are never displayed after saving.

Testing a connection

After creating or editing a source, click the Test button (wrench icon) on the source row to verify that TestOrchestrator can reach the external system with the credentials you provided.

  • A success result confirms the connection is working and the credentials are valid.
  • A failure result shows an error message — check the base URL, credentials, and that the account has sufficient permissions in the external system.

Testing does not require the source to be enabled — you can test a disabled source before enabling it.

Enabling and disabling sources

Use the toggle on each source row to enable or disable it.

  • Enabled — the source appears as an option when project members add external references.
  • Disabled — the source is hidden from project members and cannot be used to create new links. Existing links that reference this source are not removed — they remain visible but will not sync until the source is re-enabled.

Editing a source

Click the edit (pencil) icon on any source row to open the editor. All fields are editable, including auth credentials. Saving changes takes effect immediately — any running sync or webhook processing for that source will use the updated configuration on its next execution.

Deleting a source

Click the delete (trash) icon on a source row and confirm to remove the source.

Existing links are not removed. Deleting a source removes its configuration but does not delete the external reference links already created by project members. Those links will remain visible but will lose the ability to sync — they will no longer show updated issue status or assignee from the deleted source.

Project assignment

Project assignment controls source visibility at the project level. Use All projects for workspace-wide sources (e.g., a single company-wide Jira) and Specific projects when different teams use different trackers or when you want to limit which teams can link to a particular system.

Changing project assignment does not affect existing links — it only controls whether team members can create new links using this source in the relevant projects.