Connecting Jira and Azure DevOps

What the connectors import, how run results are pushed back as a single maintained comment, and the decisions behind dedupe, credentials, and eligibility.

Practitioner4 min readUpdated 17 August 2026

Nobody adopts a requirements platform into an empty room. The work already lives somewhere, usually Jira or Azure DevOps, and a tool that demands you abandon that is a tool that gets evaluated and declined.

ReqLens connects to both. This covers what actually moves in each direction and the decisions that shaped it, because the decisions are the part that determines whether an integration is useful or merely present.

Importing work in

Items are brought in from Jira or Azure DevOps as requirements, which then go through the same pipeline as anything typed directly: elaboration, decomposition, use cases, test design.

Dedupe is warn and allow. Before importing, the preview marks items you have already imported. It does not block them.

That is a deliberate choice and worth explaining, because blocking is the obvious design. Blocking assumes a re-import is always a mistake. It frequently is not: the item changed materially, or the first import was against a stale version, or you want a second requirement from an item that turned out to contain two. Warning gives you the information; deciding is yours. Every import is recorded either way, so provenance survives the choice.

The pattern to notice

Where a rule can be enforced or surfaced, ReqLens tends to surface it. Enforcement is reserved for cases where proceeding is genuinely incoherent, like a decomposition returning one feature.

Pushing results back

When a test run completes, its result summary can be pushed back to the linked work item as a comment.

Four properties of that push are worth knowing:

  1. One comment per run, maintained rather than repeated. The first push creates a comment and remembers it. A later push updates that same comment. If someone deleted it, the next push recreates it. Your ticket does not accumulate ten near-identical result comments.
  2. The destination is derived, never supplied. The target is resolved from the run's own import link. A client cannot ask for the summary to be posted somewhere else.
  3. Eligibility is re-checked server side. The run must be completed, the suite must have an import link, and push-back must be enabled for that source. All three are verified at push time and fail loudly, so an in-progress run cannot be pushed even by a stale interface offering the button.
  4. The numbers cannot contradict your reports. The pass rate in the comment reuses the same definition ReportAI uses, over executed tests. One definition, one source, no drift between the ticket and the dashboard.

Push-back is a read then write over data that already exists. No generation, nothing in the pipeline is modified.

Credentials

Connections authenticate with a personal access token. Three things about how it is held:

  • Encrypted at rest, with the key held only in the environment. There is no plaintext fallback: a missing or invalid key fails immediately rather than degrading.
  • Never returned to the client. Connection status exposes only the base URL and the account, never the token.
  • Owned by the workspace, not the person. The connection is scoped to the organisation, so it survives whoever set it up leaving, and it is not silently duplicated per member.

That last point is a small decision with a large consequence. Credentials scoped to an individual create an integration that breaks on a departure and a support conversation that nobody enjoys.

What this is and is not

It is a one way import plus a targeted result push. It is not a bidirectional sync, and that is intentional. Continuous two way sync between two systems that both consider themselves authoritative is the fastest route to conflicts nobody can adjudicate, and the resolution rules are always wrong for somebody.

The narrower model is honest about which system owns what: your tracker owns delivery workflow, ReqLens owns requirement structure and test evidence, and the connection moves specific things in specific directions at specific moments.

Key takeaways

  • Import dedupe warns rather than blocks, because a re-import is not always a mistake.
  • Push-back maintains one comment per run instead of appending a new one each time.
  • The push destination is derived from the run's own import link, never accepted from the client.
  • Credentials are encrypted, never returned, and owned by the workspace rather than the person.

Worth checking before you connect

Confirm which project or board you want items from, and that the account behind the token has the access you expect. An import that silently returns fewer items than you anticipated is almost always a permissions boundary rather than a connector problem.

Part of a learning path

Keep reading