Reqflo Docs
IntegrationsJira

Link Jira work to an existing journey

Use journey-first validation to connect Jira work to workflows that already exist in Reqflo.

Link Jira Work to an Existing Journey

Category: Integrations

Use journey-first validation when the workflow already exists in Reqflo and needs to be connected to Jira work.

This is the primary workflow for teams that use Reqflo as their workflow validation system.

Purpose

Journey-first validation links existing executable workflows to the Jira work they support.

This workflow starts from a Reqflo journey and connects relevant Jira issues, allowing teams to track coverage, completion, and evidence against planned work.

Use this workflow when the team already knows the workflow that needs to be validated.

Best-fit use cases

Use this workflow for:

  • Existing API workflows
  • Regression journeys
  • Release-critical workflows
  • Support runbooks
  • Customer-impacting workflows
  • Platform-owned capabilities
  • Reusable validation flows
  • Workflows shared across multiple Jira stories
  • Long-lived business processes

Examples:

  • Tenant onboarding
  • Checkout
  • Payment failure handling
  • Account provisioning
  • User invitation
  • Subscription upgrade
  • Partner integration setup
  • Order fulfillment
  • Customer support escalation

Inputs

This workflow starts with an existing Reqflo journey.

Useful journey fields include:

  • Journey title
  • Description
  • Scenarios
  • Variants
  • Tags
  • Linked services
  • Request templates
  • Endpoints
  • Existing run history
  • Existing evidence

Useful Jira fields include:

  • Issue summary
  • Description
  • Acceptance criteria
  • Labels
  • Components
  • Epic
  • Status
  • Sprint
  • Fix version

Workflow steps

1. Open the journey

Open the Reqflo journey that represents the workflow you want to connect to Jira.

Example:

Tenant onboarding

Open the Jira linking panel from the journey page.

3. Review suggested Jira issues

Reqflo suggests likely Jira issues based on the journey context.

Matching signals may include:

  • Journey title
  • Scenario names
  • Variant names
  • Journey tags
  • Linked services
  • Endpoint names
  • Request template names
  • Jira issue titles
  • Jira descriptions
  • Jira labels
  • Jira components
  • Epic relationship

4. Select relevant Jira work items

Choose the Jira issues that the journey validates or supports.

Example:

REQFLO-8 - Create tenant onboarding API
REQFLO-7 - Add billing setup step
REQFLO-6 - Validate invite flow permissions

A single journey may validate multiple Jira issues.

A single Jira issue may also be supported by multiple journeys when the work affects more than one workflow.

5. Review linked work on the journey

The journey now shows the Jira work items connected to it.

The linked work section should show:

  • Jira issue key
  • Issue summary
  • Issue status
  • Coverage status
  • Latest run status
  • Evidence status
  • Last updated timestamp

6. Map Jira work to scenarios

Connect each Jira work item to the scenarios it affects.

Example:

REQFLO-6 - Validate invite flow permissions

Mapped scenarios:
- Admin invites user to tenant
- Non-admin cannot invite user
- Existing user receives appropriate invite response

This makes coverage specific and auditable.

7. Review coverage and completion

Use the journey coverage view to identify what is complete and what still needs work.

The journey should show:

  • Linked Jira work items
  • Scenarios per work item
  • Variant coverage
  • Request mapping status
  • Latest run status
  • Evidence freshness
  • Completion percentage
  • Blocking gaps

8. Run the journey

Execute the journey manually, through CI, from a runbook, or from another workflow trigger.

Run results become evidence for the linked Jira work.

9. Use the journey as the validation source of truth

The journey becomes the operational record for the workflow.

It shows:

  • What the workflow is
  • Which Jira work it supports
  • Which behaviors are covered
  • Which variants are tested
  • What has passed or failed
  • What evidence exists
  • What is blocking completion

Output

At the end of this workflow, Reqflo should produce:

  • Existing journey linked to Jira work
  • Jira work mapped to scenarios
  • Scenario and variant coverage
  • Request mapping status
  • Latest run evidence
  • Completion percentage
  • List of blocking gaps
  • Readiness status

SDLC value

Journey-first validation supports long-lived workflow quality.

Many important API workflows outlive a single Jira issue. They are touched repeatedly across releases, customer requests, bug fixes, and platform changes.

By linking Jira work to existing journeys, teams avoid recreating validation from scratch for every ticket.

This improves:

  • Regression coverage
  • Release readiness
  • Reuse of validation workflows
  • Cross-team visibility
  • Supportability
  • Operational confidence
  • Evidence continuity

Reqflo becomes the place where the team can see whether a workflow is still healthy as Jira work changes over time.

StateMeaning
ExistingJourney already exists in Reqflo
LinkedOne or more Jira work items are connected
MappedJira work is mapped to scenarios
Partially coveredSome scenarios or variants are executable
CoveredRequired scenarios and variants are executable
Evidence availableRecent run evidence exists
ValidatedLatest required run passed
Needs attentionOne or more linked items has failed, missing, or stale evidence
Ready for reviewCoverage and evidence meet the team's review threshold

Example journey view

Tenant onboarding

Linked Jira work:
REQFLO-8 - Tenant onboarding API
Coverage: 4 of 5 scenarios mapped
Latest run: Passed
Evidence: Available

REQFLO-7 - Billing setup step
Coverage: 2 of 4 scenarios mapped
Latest run: Failed
Evidence: Available

REQFLO-6 - Invite flow permissions
Coverage: 1 of 3 scenarios mapped
Latest run: Not run
Evidence: Missing

Overall completion: 67%
Blocking gaps: 3 unmapped scenarios, 1 failed run, 1 missing evidence item

On this page