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 onboarding2. Click "Link Jira work items"
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 permissionsA 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 responseThis 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.
Recommended completion states
| State | Meaning |
|---|---|
| Existing | Journey already exists in Reqflo |
| Linked | One or more Jira work items are connected |
| Mapped | Jira work is mapped to scenarios |
| Partially covered | Some scenarios or variants are executable |
| Covered | Required scenarios and variants are executable |
| Evidence available | Recent run evidence exists |
| Validated | Latest required run passed |
| Needs attention | One or more linked items has failed, missing, or stale evidence |
| Ready for review | Coverage 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