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. If you are comparing tools, the guide to choosing a requirements management tool lists the integration questions to ask in a demo.
ReqLens connects to both. This covers the workflow from a ticket to reviewed tests, 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.
From a Jira story or Azure DevOps work item to reviewed tests
The ticket stays where it is. ReqLens adds the requirement and test work around it.
- Import the item. Choose the items to bring in with a JQL query in Jira or a WIQL query in Azure DevOps, and check the preview. From Jira, ReqLens reads the summary, description, issue type and labels. From Azure DevOps, it reads the title and description, and folds the Acceptance Criteria field into the requirement text.
- Turn it into reviewable acceptance criteria. The imported item is elaborated like any other requirement, into numbered acceptance criteria your team reviews and approves. Criteria that are missing or untestable in the ticket show up here, before anyone writes a test.
- Generate test cases from the approved criteria. TestCraft proposes cases with steps, expected results and test data, each linked to the criterion it is designed to test, and every case starts as a draft for review. See the AI test case generator for a full worked example.
- Run the approved suite. TestExecute records a result for each case, and failures become defects linked to the case and the requirement.
- Push the result back to the ticket. When the run completes, one maintained comment on the linked work item summarises it: suite and run, environment and build, how many cases passed, failed, were blocked or not executed, the pass rate, when the run completed, how many cases were flagged for a defect, and a link back to the run in ReqLens. Write-back is turned on per source.
Jira and Azure DevOps import and push-back are included on the Pro and Team plans. Compare ReqLens plans.
Traceability across Jira, Azure DevOps and ReqLens
Each tool keeps the part of the trace it owns. The work item keeps its delivery workflow and receives the latest result summary for each run. ReqLens keeps the finer chain underneath it: from the imported requirement to its acceptance criteria, from each criterion to the test cases designed to test it, and on to execution results and defects.
That split matters because a ticket can only say whether a run passed. It cannot say which agreed criteria have no test, or which requirement a failed case puts at risk. For that view, ReqLens produces a requirements traceability matrix you can export, and every import is recorded, so the trace starts at the ticket it came from. The requirements traceability matrix template explains what the chain should contain, and requirements traceability in ReqLens shows how it is kept current.
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.
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:
- 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.
- 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.
- 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.
- 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.