Need a clean way to separate non-prod and prod defects without creating multiple projects

ALM Atlassian Jira Software
, , , , , , ,
1

Our team wants to clearly distinguish QA/Stage defects from Production defects without splitting into separate projects. We currently use a single DEV project for all bugs, but our production defect SLAs and priority handling are different from test environment issues. The team needs to filter boards and dashboards by environment, but we want to keep a unified workflow.

We’re considering adding a custom field “Environment” with values QA, Stage, Production. The field would be required on bug creation, and we’d set up board filters and swimlanes based on environment. Our concern is whether this approach scales-will it be easy to create separate quick filters, SLA rules, and automation rules per environment? Or should we use labels or components instead? We want to avoid the overhead of managing multiple projects but need clear separation for reporting and priority routing.

2

We use a custom “Environment” field in Jira 8 with great success. Make it a required field on the bug creation screen so every defect is tagged. Then set up board quick filters:


Environment = Production (for prod defects only)
Environment IN (QA, Stage) (for non-prod)

For swimlanes, you can group by Environment field value. This keeps everything in one project while giving you clear separation for prioritization and reporting.

3

Here’s a complete implementation plan for environment-based defect separation in a single Jira project:

Custom Environment Field with Fixed Values: Create a custom field for the bug issue type:

  • Field Type: Select List (single choice)
  • Field Name: “Environment”
  • Options: QA, Stage, Production (in that order)
  • Default Value: QA (so most defects default to non-prod)
  • Context: DEV project, Bug issue type only

Add this field to the bug creation screen and make it required via field configuration. This ensures every defect is tagged at creation, preventing unclassified bugs.

Required Fields on Bug Creation: Update your bug creation screen to include:

  1. Environment (required, select list)
  2. Priority (required, but allow default)
  3. Affects Version (optional, but recommended for production defects)
  4. Component (optional, for functional area)

This gives you enough metadata to route and prioritize defects without overwhelming the user.

Board Filters Using Environment Criteria: Create separate board views for different audiences:

  • Production Defects Board: Filter: `project = DEV AND type = Bug AND Environment = Production
  • QA/Stage Defects Board: Filter: `project = DEV AND type = Bug AND Environment IN (QA, Stage)
  • All Defects Board: Filter: project = DEV AND type = Bug (no environment filter)

Each board can have its own columns, swimlanes, and quick filters tailored to the team using it.

Swimlanes and Quick Filters per Environment: On the All Defects Board, configure:

  • Swimlanes: Group by Environment field (creates 3 swimlanes: Production, Stage, QA)
  • Quick Filters:
    • “Prod Only”: `Environment = Production
    • “Non-Prod”: `Environment IN (QA, Stage)
    • “Critical Prod”: `Environment = Production AND Priority = Critical
    • “Unresolved Prod”: `Environment = Production AND resolution is EMPTY This lets users toggle views without switching boards.

Unified Workflows for All Defects: Keep a single bug workflow (Open → In Progress → Resolved → Closed) for all environments. Don’t create separate workflows per environment-this adds unnecessary complexity. Instead, use automation rules to handle environment-specific behavior:

Automation Rule 1: Production Defect Notifications


TRIGGER: Issue created
CONDITION: Issue type = Bug AND Environment = Production
ACTION: Send email to production-support@company.com
ACTION: Add label "production-defect"
ACTION: Set Priority to High (if not already Critical)

Automation Rule 2: Warn on Critical Non-Prod Defects


TRIGGER: Field value changed (Priority)
CONDITION: Priority changed to Critical AND Environment IN (QA, Stage)
ACTION: Add comment: "Warning: Critical priority is typically reserved for Production defects. Please verify this is correct."

Automation Rule 3: Auto-Escalate Stale Production Defects


TRIGGER: Scheduled (daily at 10 AM)
CONDITION: JQL query: type = Bug AND Environment = Production AND status = Open AND created < -2d
ACTION: Add comment tagging manager: "@prod-manager This production defect has been open for 2+ days."
ACTION: Add label "stale-prod-defect"

SLA Rules per Environment (via Marketplace Plugin): If you install a plugin like “Time to SLA for Jira,” configure:

  • SLA 1 (Production Critical): IF Environment = Production AND Priority = Critical THEN Time to First Response = 4 hours, Time to Resolution = 24 hours
  • SLA 2 (Production High): IF Environment = Production AND Priority = High THEN Time to First Response = 8 hours, Time to Resolution = 48 hours
  • SLA 3 (Non-Prod): IF Environment IN (QA, Stage) THEN Time to First Response = 24 hours, Time to Resolution = 1 week

These SLA rules automatically apply based on the Environment field value, giving you differentiated service levels without separate projects.

Dashboard and Reporting: Create executive dashboards with gadgets filtered by environment:

  • Gadget 1 (Production Defects): Pie chart showing production bug status distribution
  • Gadget 2 (Environment Breakdown): Bar chart of bug count by Environment field
  • Gadget 3 (SLA Compliance): SLA plugin gadget filtered to Environment = Production only
  • Gadget 4 (Trend): Line chart of created vs resolved bugs, filtered by Environment

Export these dashboards as PDF for weekly management reviews.

Advantages of This Approach:

  1. Single Project: No overhead of managing multiple projects, workflows, or permission schemes
  2. Flexible Filtering: Teams can view defects by environment without data silos
  3. Unified Workflow: One workflow to maintain, with environment-specific behavior via automation
  4. Scalable Reporting: Custom field enables precise JQL queries and dashboard filtering
  5. Clear Separation: Production defects get priority routing and SLA tracking, while QA defects stay low-noise

Potential Pitfalls to Avoid:

  • Don’t use Labels for environment-too easy to misspell or create duplicates
  • Don’t use Components for environment-they’re meant for functional areas (UI, API, Database)
  • Don’t create separate workflows per environment-adds complexity without benefit
  • Don’t make Environment field editable after creation-lock it down to prevent accidental changes

Implementation Steps:

  1. Create “Environment” custom field with fixed values (QA, Stage, Production)
  2. Add field to bug creation screen and make it required
  3. Create board filters and swimlanes based on Environment
  4. Deploy automation rules for production defect notifications and warnings
  5. Install SLA plugin and configure environment-specific SLA goals (if needed)
  6. Build executive dashboards with environment-filtered gadgets
  7. Train team on when to use each environment value

This solution gives you clean environment separation, differentiated SLA handling, and flexible reporting-all within a single Jira project using native features plus one optional SLA plugin. No need for multiple projects, complex workflows, or custom development.

4

The quick filter examples are helpful. But what about SLA rules-can we configure different SLA targets per environment? For example, Production defects need 4-hour response time, while QA defects can wait 24 hours. Does Jira 8 support conditional SLA rules based on custom field values, or do we need a marketplace plugin?

5

Got it on SLA plugins. One more concern-if we use a unified workflow for all environments, how do we prevent QA defects from accidentally getting escalated to production severity? Should we add workflow validators that check the Environment field before allowing certain transitions, or rely on team training and board filters to keep them separate?

6

Workflow validators are overkill for this use case. The Environment field is just metadata for filtering and reporting-it doesn’t need to restrict workflow transitions. Instead, use automation rules to enforce business logic. For example:

  • Rule 1: When bug transitions to “Ready for Release,” check if Environment = Production. If yes, send notification to release manager. If no, skip.
  • Rule 2: When Priority is set to “Critical,” check if Environment = QA or Stage. If yes, add a comment warning the user that Critical priority should be reserved for Production defects.

This gives you soft enforcement without blocking workflows, and it educates the team over time.