Integrations: Jira, Xray, Azure DevOps, Slack and Telegram

Nexus Studio connects to five services: Jira Cloud, Xray Cloud, Azure DevOps, Slack and Telegram. Each one is off until you switch it on, and each one is reached straight from your machine, never through our servers. This page explains what each one does, the keys it reads, and what it never does.

By the Nexus Studio team, Verdict System LLC. October 9, 2026.

How every integration works

• Off until you switch it on. Each service has its own switch: JIRA_ENABLED, XRAY_ENABLED, AZURE_BOARDS_ENABLED, SLACK_ENABLED and TELEGRAM_ENABLED. Every one is false by default.
• Straight from your machine. The engine calls each service's own API from the machine that runs the tests. Nothing goes through our servers, and we never see your issues, alerts or results.
• Keys stay in the workspace. Tokens and keys are lines in the workspace's .env file, on your disk. Settings, under Integrations, edits them and shows every token, key and webhook redacted.
• Sandbox runs stay out. A sandbox run is a test under construction, not a finding: it never files, comments on or closes an issue.

One issue per test, for as long as it stays broken

Jira and Azure Boards follow the same lifecycle. The issue belongs to the test, not to the run, so a test that fails every night is one issue with a history, not a new issue every night.

1. The first failure opens one issue. A run that ends BREACHED, BREACHED_FLAKY, CHAOS_BREACHED or TIMEOUT opens one issue for that test, with the error and the failure's screenshot attached.
2. A repeat failure comments on it. While that issue is open, the next failure adds a comment to it, with the new screenshot attached. Two browsers that fail at once add to the same issue.
3. A clean pass closes it. When the test passes clean on every browser of a run, the issue gets a comment saying so and moves to its done state. If the workflow has no such transition or state, it gets the comment only.
4. A failure after that opens a new issue. So does a failure whose issue was deleted or moved.

Attachments: the screenshot only, by default. The Playwright trace and the run log are attached too only if you opt in with NEXUS_ISSUE_ATTACH_TRACE=true in Settings, because they may contain session data: cookies, authorization headers and typed passwords. Each file is attached up to 10 MB.

FLAKY never files anything: a run that failed and then passed on a retry is not a bug. Neither do BLOCKED, UNREACHABLE, CRASHED or a configuration error, which are about the environment, not your application (how verdicts are decided). Which issue belongs to which test is kept in evidence/integrations/issue-map.json, in the workspace.

Jira Cloud

• Connect: your Atlassian account email and an API token, created at id.atlassian.com. In Settings, under Integrations, paste any link from your Jira site: the Studio keeps the site and the project key. The site address, JIRA_BASE_URL, must be https. Check connection tests them and creates nothing.
• Issues: a Bug in JIRA_PROJECT_KEY, following the lifecycle above. On a clean pass, the issue moves through the transition named in JIRA_DONE_TRANSITION, Done by default, matched by name in any case.
• No duplicates: if a Bug with the same summary was created in the last 24 hours, no second one is filed.
• By hand: the Evidence Locker can send a failure to Jira when you choose to.

Xray Cloud

With XRAY_ENABLED=true, every nexus ci run imports its JUnit XML into Xray Cloud as a Test Execution, in XRAY_PROJECT_KEY, or in JIRA_PROJECT_KEY when that is blank, and under the Test Plan in XRAY_TEST_PLAN_KEY when you set one.

• Connect: an API key pair, XRAY_CLIENT_ID and XRAY_CLIENT_SECRET, created in Jira under Apps, Xray, Global settings, API keys.
• What leaves: the JUnit file of that run, and nothing else. A JUnit file left by an earlier run is never imported.
• Never fails the run: if the import fails, the run's log says why in one line, with the secret blanked out.

Azure DevOps: Boards, Test Plans and Pipelines

One personal access token (PAT) and one project, in AZURE_DEVOPS_ORG_URL (https://dev.azure.com/<org> or https://<org>.visualstudio.com) and AZURE_DEVOPS_PROJECT. The PAT is sent only to Azure DevOps' own hosts and never appears in a log line. In Settings, under Integrations, Connect Azure DevOps checks the project and the work item type, and creates nothing.

• Azure Boards: with AZURE_BOARDS_ENABLED=true, a failure opens a work item of type AZURE_BOARDS_WORK_ITEM_TYPE, Bug by default, following the lifecycle above. On a clean pass it moves to the state in AZURE_BOARDS_DONE_STATE, Resolved by default; a process that refuses that state gets the comment only. The PAT needs Work Items (Read & write). The Evidence Locker can also send a failure to Azure Boards by hand.
• Azure Test Plans: the azure-pipelines.yml the CI/CD screen generates publishes the run's JUnit XML with the PublishTestResults@2 task, so every pipeline run appears under Test Plans, Runs.
• Azure Pipelines: nexus ci-remote --provider=azure queues a run of the pipeline in AZURE_PIPELINE_ID, waits for it, and brings its JUnit XML back to this machine. The PAT needs Build (Read & execute) for this.

Slack

• Connect: one Incoming Webhook URL, in SLACK_WEBHOOK_URL. Settings has a Send test message button.
• What it gets: Block Kit messages: the run summary, and, with NEXUS_SLACK_NOTIFY=true, one message per failing, flaky, chaos or visual regression test. A message about a failure links its Jira issue when there is one.
• By hand: the Evidence Locker can post a failure's text summary to Slack. Slack gets no files.

Telegram

• Connect: a bot of your own, created once with @BotFather, in TELEGRAM_TOKEN. In Settings, Connect by QR pairs your chat and fills TELEGRAM_CHAT_ID. There is no shared bot.
• What it gets: alerts on failure, one per test with NEXUS_TELEGRAM_NOTIFY=true, and the reports and files you choose to share from the Studio.
• Before you switch it on: Telegram can receive files, such as reports and PDFs, and they go to Telegram's servers. In a regulated environment, ask your compliance team first.

The keys

Every key is a line in the workspace's .env. Settings edits all of them.

In a pipeline, the same keys, all but AZURE_PIPELINE_ID, are the pipeline's secret variables, and a key you leave unset keeps its service off (secrets in CI/CD).

Questions

Does Nexus Studio see my Jira or Azure DevOps data?

No. The engine talks to Jira, Xray, Azure DevOps, Slack and Telegram from your machine, with your keys. None of it passes through our servers.

Will a flaky test open a ticket?

No. FLAKY files nothing. BREACHED_FLAKY does: the failure itself was inconsistent, and a retry does not hide it.

A test failed 30 times this week. How many issues is that?

One, with a comment and a fresh screenshot for each failure after the first, until the test passes clean on every browser.

Can I use Jira and Azure Boards at once?

Yes. Each one keeps its own issue per test.