Status and Environment fields help standardize how campaigns are classified and executed. They ensure consistency across the project while keeping campaign tracking clear and structured.
Why it matters
- Workflow clarity: Status reflects where the campaign stands (Draft, In Progress, Completed, etc.).
- Execution context: Environment defines where the campaign is being validated (Staging, QA, Production-like, etc.).
- Team alignment: Shared values prevent confusion and inconsistent labeling.
When to use it
- When creating a new campaign to properly classify its lifecycle stage.
- When moving from testing to validation (for example, Draft → In Progress → Completed).
- When executing the same campaign across multiple environments (e.g., Staging vs Pre-Production).
Core concepts
- Status – a configurable campaign state that reflects progress
- Environment – a configurable label representing the execution target
- Dynamic lists – statuses and environments are centrally managed and reusable across campaigns
- Consistency – standard values ensure reporting and filtering remain clean
How it works
- Status and Environment values are managed as shared lists within the project.
- When creating or editing a campaign, you select values from these predefined lists.
- The selected values become part of the campaign metadata and appear in listings and filters.
- Updates to these lists affect future selections while preserving historical campaign records.
How to use it
Step 1: Add or maintain Status values
Define clear workflow states such as Draft, In Progress, Blocked, or Completed. Keep the list simple and aligned with your team process.
Step 2: Add or maintain Environment values
Create environment labels that reflect real execution targets (for example: Local QA, Staging, Production Mirror).
Step 3: Assign values when creating a campaign
Select the appropriate Status and Environment when defining the campaign to ensure proper classification and filtering.
Step 4: Update status during execution
As the campaign progresses, update its Status to reflect the current stage of validation.
Campaign Execution Result Behavior (API Execution)
When a Test Campaign is executed through API-based execution:
- All test cases inside the campaign are executed sequentially based on their defined Order.
- If a campaign contains 5 test cases, they will run in order (1 → 2 → 3 → 4 → 5).
- Each test case updates its own execution results internally as it completes.
- The campaign does not merge or override individual case history; instead, it records results directly within each test case.
- After all test cases finish, the campaign returns a structured JSON response containing the aggregated results and responses from all executed test cases.
This ensures that:
- Individual test case history remains accurate and traceable.
- Campaign-level execution provides a combined summary view.
- Sequential execution maintains logical flow and dependency order.
Best practices
- Keep Status workflow simple: avoid creating too many states.
- Name Environments realistically: match actual infrastructure names.
- Update Status consistently: don’t leave campaigns marked as Draft after execution.
- Use Environment filtering: especially when validating the same scope across multiple targets.
Common mistakes
❌ Creating too many Status values
✔ Limit workflow states to what the team actually uses.
❌ Using inconsistent environment names
✔ Standardize naming (avoid duplicates like “stage”, “staging”, “STG”).
❌ Assuming campaign results replace test case results
✔ Campaign execution updates each test case individually and returns an aggregated summary at the end.
Security & permissions
- Status and Environment management follows project-level permission rules.
- Only authorized roles can modify shared lists.
- Campaign execution respects execution permissions defined at the project level.
Related documentation
- Test Campaign Overview
- Managing Campaign Test Cases
- Running a Test Campaign
- Test Case Execution