Orchestrating Requirements with Processes

In Catalio, a Process is a structured workflow that orchestrates multiple requirements in a specific sequence. Think of processes as your implementation playbook—they define the exact steps, order, and team coordination needed to deliver complex features or systems.

Unlike scattered requirement lists, processes provide:

• Sequential Organization: Requirements ordered in the right implementation sequence
• Team Coordination: Clear assignment of who implements each requirement
• Deployment Tracking: Real-time visibility into progress from planning to production
• Reusable Templates: Clone proven workflows for new projects

Templates vs Instances: The Power of Reusability

Catalio processes follow a powerful template-instance pattern that eliminates duplicate work:

Templates: Your Workflow Blueprints

A template is a reusable process definition containing:

• A standard sequence of requirements
• Typical team assignments
• Proven implementation patterns
• Step labels and optional vs required indicators

Templates are marked with is_template: true and serve as master blueprints for common workflows.

Example Templates:

• “Salesforce Validation Rule Implementation”
• “New API Endpoint Development”
• “Customer Onboarding Flow Setup”
• “Monthly Compliance Reporting Process”

Instances: Project-Specific Workflows

An instance is a concrete process cloned from a template for a specific project. Each instance:

• Inherits all requirements from the template
• Can be customized for the specific context
• Tracks its own deployment progress
• Links back to the template via template_id

How It Works:

1. Create Template Once: Build a “Salesforce Validation Rule Implementation” template with all standard steps
2. Clone for Projects: Create “Account Validation - Q1 Project” instance by cloning the template
3. Customize: Adjust team assignments, add project-specific requirements, modify order
4. Track Progress: Monitor deployment independently per instance
5. Reuse: Clone the same template again for “Opportunity Validation - Q2 Project”

Benefits of Template-Instance Pattern

• Consistency: Every project follows proven workflows
• Efficiency: No manual recreation of common processes
• Continuous Improvement: Update templates based on lessons learned
• Onboarding: New team members see established patterns
• Governance: Standardize critical workflows across organization

Pro Tip: Start with 3-5 well-documented templates for your most common workflows. You’ll save hours of planning time on every new project.

Process Types: Categorizing Your Workflows

Catalio recognizes three fundamental process types based on operational impact:

Operational Processes

Definition: Core processes that directly create customer value and generate revenue.

Examples:

• Manufacturing products
• Fulfilling customer orders
• Delivering professional services
• Handling customer support requests
• Processing loan applications
• Onboarding new customers

Characteristics:

• Customer-facing impact
• Direct revenue generation
• High frequency execution
• Quality directly affects customer satisfaction

Management Processes

Definition: Processes that govern how the organization operates and makes decisions.

Examples:

• Strategic planning cycles
• Budget allocation and review
• Performance management systems
• Risk assessment workflows
• Governance and compliance reviews
• Quarterly business reviews

Characteristics:

• Organization-wide impact
• Lower frequency (monthly/quarterly/annually)
• Decision-making focus
• Sets direction for operational processes

Supporting Processes

Definition: Processes that enable core business operations but don’t directly create customer value.

Examples:

• HR recruitment and onboarding
• IT support ticket resolution
• Accounting and financial close
• Facilities management
• Legal contract review
• Software deployment pipelines

Characteristics:

• Internal service delivery
• Enable operational processes
• Infrastructure and foundation focus
• Quality affects operational efficiency

Why Categorize? Process types help you prioritize improvements, allocate resources, and understand organizational dependencies. Operational process failures impact customers immediately; supporting process issues affect internal efficiency.

Process Lifecycle: The State Machine

Every process moves through a well-defined lifecycle managed by Catalio’s state machine. This ensures processes transition through proper gates with appropriate validations.

Implementation Journey: Draft → Active

1. Draft

Initial state - Process is being planned and refined.

• Freely edit requirements, order, and team assignments
• Add or remove requirements without restrictions
• Perfect for stakeholder collaboration and planning
• No deployment tracking active yet

Typical Activities:

• Define the workflow sequence
• Identify required requirements
• Assign preliminary teams
• Document step labels and dependencies

Transition: Begin Development → moves to In Development

2. In Development

Active implementation - Teams are building the requirements.

• Requirements are actively being coded and tested
• Team assignments finalized
• Deployment tracking begins
• Changes tracked via audit trail

Typical Activities:

• Developers implement requirements
• Code reviews and testing
• Mark requirements as in_development state
• Coordinate team dependencies

Transition: Move to Testing → moves to In Testing

3. In Testing

Quality assurance - Implementation complete, undergoing validation.

• All coding complete for current scope
• QA teams actively testing
• Bugs being fixed
• Requirements in in_testing deployment state

Typical Activities:

• Execute test plans
• Reproduce and verify bug fixes
• Validate acceptance criteria
• Prepare staging deployment

Transition: Move to Staging → moves to In Staging

4. In Staging

Pre-production validation - Testing in staging environment.

• Deployed to staging environment
• Final validation before production
• Stakeholder acceptance testing
• Performance and integration verification

Typical Activities:

• Smoke tests in staging
• User acceptance testing
• Load testing
• Documentation review

Transitions:

• Partially Deploy → moves to Partially Deployed (some requirements ready for production)
• Activate → moves to Active (all requirements deployed and verified)

5. Partially Deployed

Incremental rollout - Some requirements in production, others pending.

• Phased deployment approach
• Early requirements deployed
• Later requirements still in staging
• Mixed deployment states tracked per requirement

Use Case: Large processes deployed in waves to manage risk and coordinate team availability.

Transition: Activate → moves to Active (when all requirements reach deployed state)

6. Active

Production operation - All requirements deployed, process is live.

• All requirements in deployed state
• Process delivering value in production
• Monitored for performance and issues
• Business Rule: Cannot activate until all requirements are deployed

Typical Activities:

• Monitor production metrics
• Gather user feedback
• Identify improvement opportunities
• Plan future updates

Transitions:

• Begin Update → moves to Updating (plan improvements)
• Deprecate → moves to Deprecated (phase out)

Maintenance and Retirement

7. Updating

Planning improvements - Designing updates to active process.

• Process remains live in production
• Team planning next version
• Requirements being added or modified
• Coordination with operations for deployment timing

Transition: Continue Update → moves back to In Development (implement updates)

8. Deprecated

Phase-out period - No longer recommended but still accessible.

• Process marked as outdated
• Migration to replacement process encouraged
• Still accessible for reference and support
• No new instances should be created

Example Reason: “Replaced by Process v2.0 using new API architecture”

Transition: Archive → moves to Archived

9. Archived

Historical record - Process preserved for audit purposes only.

• Hidden from normal operational views
• Preserved for compliance and audit
• Cannot be reactivated
• Linked instances and requirements preserved

Use Cases:

• Regulatory compliance requiring historical records
• Post-mortem analysis of past approaches
• Audit trails for decision-making

Transition: Cancel (from Draft) → direct archival of draft processes never implemented

State Machine Business Rules

Catalio enforces critical business rules via state transitions:

1. Active Requires Requirements: Cannot activate a process without at least one requirement
2. Deployment Validation: Cannot activate until all requirements reach deployed state
3. Template Protection: Templates with instances cannot be deleted (data integrity)
4. Audit Trail: All state transitions tracked with who, when, and why

Orchestrating Requirements: Building Your Workflow

The core value of processes is orchestrating multiple requirements into a cohesive implementation plan.

Adding Requirements to Processes

Requirements are added via the ProcessRequirement join resource, which captures:

• The Requirement: Which capability is being implemented
• Order: Sequential position in the workflow
• Step Label: Human-readable identifier like “Phase 1”, “Step 2.3”, “Pre-Deployment”
• Team Assignment: Which team implements this requirement
• Deployment State: Current progress status
• Is Optional: Whether this requirement can be skipped
• Dependencies: Team coordination needs (blocking vs non-blocking)

Sequential Ordering

The order field defines implementation sequence:

Order 1: "Create database schema" (Infrastructure Team)
Order 2: "Build API endpoints" (Backend Team) - depends on #1
Order 3: "Implement UI components" (Frontend Team) - depends on #2
Order 4: "Add validation rules" (Backend Team)
Order 5: "Deploy to staging" (DevOps Team) - depends on #3, #4
Order 6: "Run acceptance tests" (QA Team) - depends on #5
Order 7: "Deploy to production" (DevOps Team) - depends on #6

Parallel Requirements: Set same order number for requirements that can be implemented
simultaneously

Order 1: "Setup CI/CD pipeline" (DevOps)
Order 1: "Create test fixtures" (QA) - parallel with CI/CD
Order 2: "Implement feature" (Dev) - depends on both

Nil Order: Use nil for unordered/parallel groupings when sequence doesn’t matter.

Step Labels for Clarity

Step labels provide human-readable context beyond numeric ordering:

• Phase-Based: “Phase 1: Foundation”, “Phase 2: Core Features”, “Phase 3: Polish”
• Milestone-Based: “MVP”, “Beta”, “General Availability”
• Sequential: “Step 1”, “Step 2.1”, “Step 2.2”, “Step 3”
• Functional: “Pre-Deployment”, “Deployment”, “Post-Deployment Validation”

Step labels appear in UI, reports, and team dashboards for quick orientation.

Optional vs Required Steps

Mark requirements as optional when they’re nice-to-have but not blocking:

Required (default):

• Core functionality
• Critical validations
• Security controls
• Regulatory compliance

Optional:

• Performance optimizations
• Nice-to-have UI polish
• Additional analytics
• Future enhancements

Business Impact: Optional requirements can be deferred if schedule pressure requires trade-offs, while required steps must be completed before activation.

Team Assignment and Coordination

Assign specific teams to each requirement for clear accountability:

REQ-001: "Database Migration" → Infrastructure Team
REQ-002: "API Development" → Backend Team
REQ-003: "UI Implementation" → Frontend Team
REQ-004: "Security Review" → Security Team
REQ-005: "Documentation" → Technical Writing Team

Dependencies Map: Use the dependencies JSONB field to capture team coordination needs:

{
  "infrastructure_team_id": {
    "type": "blocking",
    "description": "Must complete database schema before API development"
  },
  "security_team_id": {
    "type": "non_blocking",
    "description": "Security review in parallel, feedback addressed iteratively"
  }
}

Blocking Dependencies: Work cannot proceed until dependency is resolved. Non-Blocking Dependencies: Work proceeds in parallel, coordination happens iteratively.

Deployment Tracking: From Planning to Production

ProcessRequirement deployment states provide real-time visibility into implementation progress:

Deployment States

Pending

Definition: Requirement not yet started.

• Initial state for all requirements
• Team assigned but work hasn’t begun
• Appears in backlog views

Example: Database schema requirement waiting for infrastructure team capacity.

In Development

Definition: Team actively implementing the requirement.

• Code being written
• Design decisions being made
• Work in progress

Example: Backend developers building the new API endpoint.

In Testing

Definition: Implementation complete, undergoing validation.

• Code complete and in review
• QA team executing test cases
• Bugs being identified and fixed

Example: QA validating the new validation rule in test environment.

Deployed

Definition: Successfully deployed to production.

• Live in production environment
• Verified working correctly
• deployed_at timestamp recorded
• deployed_by user captured

Business Impact: This is the critical state that gates process activation. All requirements must reach deployed before the process can move to active state.

Example: Validation rule live in production Salesforce org, verified by stakeholders.

Rolled Back

Definition: Deployment was reversed due to issues.

• Production deployment failed or caused problems
• Changes reverted to previous state
• Issue investigation underway
• May return to in_development for fixes

Example: API endpoint deployed but caused performance issues, rolled back for optimization.

Deployment Progress Monitoring

Catalio provides built-in visibility into deployment progress:

Process-Level Metrics:

• Total requirements: 12
• Pending: 2
• In Development: 4
• In Testing: 3
• Deployed: 3
• Rolled Back: 0
• Progress: 25% deployed (3/12)

Team-Level Metrics:

• Backend Team: 3 requirements, 1 deployed, 1 in testing, 1 in development
• Frontend Team: 4 requirements, 2 deployed, 2 in testing
• DevOps Team: 2 requirements, 0 deployed, 1 in testing, 1 pending

Timeline View:

• Week 1: 3 requirements deployed (foundation)
• Week 2: 2 requirements deployed (core features)
• Week 3: 4 requirements in testing (UI polish)
• Week 4 target: Final 3 requirements to production

Use Case Selection per Requirement

ProcessRequirement includes selected_use_case_ids array to specify which use cases apply to each requirement in the process context:

Why This Matters: A requirement might have 5 defined use cases, but in a specific process, only 2 are relevant.

Example:

Requirement: “User Authentication” All Use Cases:

1. Login with email/password
2. Login with OAuth2 (Google)
3. Login with OAuth2 (Microsoft)
4. Password reset flow
5. Multi-factor authentication

Process Instance: “Q1 MVP Launch” Selected Use Cases for this Process:

• Use Case 1: Login with email/password (MVP critical)
• Use Case 2: Login with OAuth2 (Google) (MVP critical)
• Use Case 3 (deferred to Q2)
• Use Case 4 (deferred to Q2)
• Use Case 5 (deferred to Q3)

This granular control ensures teams focus on the right scope for each process iteration.

Complete Example: Salesforce Validation Rule Implementation

Let’s walk through a complete process from template to production.

Step 1: Create the Template

Process Template: “Salesforce Validation Rule Implementation” Type: Operational Description: “Standard workflow for implementing new Salesforce validation rules with proper testing and deployment”

Requirements in Template:

Deployment States: All start in pending when template is cloned.

Step 2: Clone for Specific Project

Clone Template → Create Instance

New Process Instance: “Account Validation Rules - Q1 2025” Type: Operational (inherited) Template Link: References “Salesforce Validation Rule Implementation” template Status: Draft Customization:

• Change team assignments for company-specific teams
• Add project-specific requirement: “REQ-110: Update training materials”
• Adjust order based on team availability

Step 3: Execute the Workflow

Week 1: Planning Phase

Process Status: Draft → In Development (Begin Development action)

REQ-101: Pending → In Development (Business Analyst started)
REQ-102: Pending → In Development (QA created test plan)

Week 2: Development Phase

REQ-101: In Development → In Testing (BA validated logic)
REQ-102: In Development → In Testing (QA reviewed test scenarios)
REQ-103: Pending → In Development (Dev implementing formula)
REQ-104: Pending → In Development (Dev adding help text)

Week 3: Testing Phase

Process Status: In Development → In Testing (Move to Testing action)

REQ-101: In Testing → Deployed (Logic approved)
REQ-102: In Testing → Deployed (Test plan approved)
REQ-103: In Development → In Testing (Formula in sandbox)
REQ-104: In Development → In Testing (Help text ready)
REQ-105: Pending → In Development (QA executing tests)

Week 4: Staging and Deployment

Process Status: In Testing → In Staging (Move to Staging action)

REQ-103: In Testing → Deployed (Formula verified in staging)
REQ-104: In Testing → Deployed (Help text approved)
REQ-105: In Development → In Testing (Test cases executed)
REQ-106: Pending → In Development (Stakeholder UAT started)

Week 5: Production Deployment

Process Status: In Staging → Partially Deployed (Partially Deploy action)

REQ-105: In Testing → Deployed
REQ-106: In Development → Deployed
REQ-107: Pending → In Development → Deployed (Production deployment)
REQ-108: Pending → In Development → Deployed (Production verification)

Week 6: Completion

REQ-109: Pending → In Development → Deployed (Docs updated)
REQ-110: Pending → In Development → Deployed (Training completed)

Process Status: Partially Deployed → Active (Activate action)
All Requirements: Deployed ✓
Process: Active in Production ✓

Step 4: Monitor and Improve

Production Metrics:

• Deployment Time: 6 weeks (planned: 5 weeks)
• Requirements: 10 total, 10 deployed, 0 rolled back
• Bottleneck Identified: Stakeholder UAT took 2 weeks (planned: 1 week)

Template Improvement:

• Update template to include “Schedule stakeholder UAT early” note
• Add optional requirement: “Pre-UAT demo session” to catch issues earlier
• Document lesson learned in template description

Next Instance Benefits from Lessons Learned:

• New process instances cloned from updated template
• Improved estimates based on actual data
• Proven workflow eliminates planning overhead

Best Practices for Process Management

Template Design

Do:

• ✅ Create templates for any workflow you’ll repeat 3+ times
• ✅ Include detailed step labels and descriptions
• ✅ Document typical team assignments and dependencies
• ✅ Mark truly optional requirements (don’t make everything required)
• ✅ Keep templates updated based on lessons learned
• ✅ Include deployment state expectations in descriptions

Don’t:

• ❌ Create overly generic templates that need extensive customization
• ❌ Include project-specific requirements in templates
• ❌ Make every requirement required (reduces flexibility)
• ❌ Forget to update templates after process improvements
• ❌ Create templates for one-off processes

Instance Management

Do:

• ✅ Clone from templates whenever possible
• ✅ Customize instances for project context
• ✅ Update deployment states in real-time
• ✅ Document blockers and issues as they arise
• ✅ Conduct retrospectives and feed learnings back to templates
• ✅ Archive completed instances to keep workspace clean

Don’t:

• ❌ Recreate common processes manually
• ❌ Let deployment states get stale (hurts visibility)
• ❌ Skip state transitions (breaks business rules)
• ❌ Delete instances (archive instead for audit trail)
• ❌ Ignore template improvements from instance lessons

Team Coordination

Do:

• ✅ Assign teams at the requirement level for clarity
• ✅ Document blocking vs non-blocking dependencies
• ✅ Use step labels to communicate phases
• ✅ Hold cross-team synchronization meetings for complex processes
• ✅ Update deployment states so other teams know when to start
• ✅ Use optional flags to communicate flexibility

Don’t:

• ❌ Assume teams will coordinate without explicit dependencies
• ❌ Over-serialize work that could be parallel
• ❌ Leave team assignments ambiguous
• ❌ Ignore dependency bottlenecks
• ❌ Skip deployment state updates (creates confusion)

Deployment Tracking

Do:

• ✅ Update deployment states immediately after changes
• ✅ Use deployed_at and deployed_by fields for audit trail
• ✅ Document rollback reasons for improvement
• ✅ Track metrics: cycle time, deployment frequency, rollback rate
• ✅ Hold deployment retrospectives for complex processes
• ✅ Automate state updates where possible (CI/CD integrations)

Don’t:

• ❌ Batch update deployment states (real-time is critical)
• ❌ Skip rolled_back state (masks problems)
• ❌ Ignore deployment metrics
• ❌ Rush through deployment gates
• ❌ Forget to verify production deployments

State Machine Usage

Do:

• ✅ Use state machine transitions for all status changes
• ✅ Understand business rules before attempting activation
• ✅ Validate all requirements deployed before activating
• ✅ Use updating state for planning improvements to active processes
• ✅ Deprecate processes with clear replacement paths
• ✅ Archive old processes for clean workspace

Don’t:

• ❌ Try to skip states (enforced by state machine)
• ❌ Activate processes with undeployed requirements (blocked by validation)
• ❌ Delete templates with instances (blocked by validation)
• ❌ Leave processes in perpetual draft state
• ❌ Reactivate archived processes (not supported)

Process Metrics and Reporting

Catalio automatically tracks process performance:

Process-Level Metrics

• Cycle Time: Draft → Active duration
• Deployment Velocity: Requirements deployed per week
• Rollback Rate: Percentage of deployments rolled back
• Team Utilization: Requirements assigned per team
• Completion Rate: Deployed / Total requirements

Template Effectiveness

• Instance Count: Number of times template was cloned
• Average Cycle Time: Mean time from instance creation to activation
• Success Rate: Percentage of instances reaching active state
• Improvement Trend: Cycle time decreasing over template generations

Team Performance

• Throughput: Requirements completed per sprint
• Quality: Rollback rate per team
• Velocity: Average time from assigned → deployed
• Blocking Impact: How often team dependencies block other teams

Use these metrics to identify bottlenecks, optimize workflows, and demonstrate continuous improvement.

Integration with Requirements, Personas, and Use Cases

Processes don’t exist in isolation—they orchestrate the complete specification:

Process → Requirements

• Each requirement in a process represents a specific capability
• Requirements may appear in multiple processes with different contexts
• Deployment tracking is process-specific (same requirement can be deployed in Process A but pending in Process B)

Requirements → Personas

• Requirements specify “As a [Persona]” user stories
• Processes indirectly serve personas through their requirements
• Filter processes by persona to see which workflows deliver value to specific users

Requirements → Use Cases

• Requirements define use cases as acceptance criteria
• ProcessRequirement selected_use_case_ids scopes which use cases apply to this process
• Processes validate that selected use cases are deployed before activation

Full Traceability Chain

Process: "Account Management MVP"
  ├─ REQ-001: "User Authentication"
  │   ├─ Persona: "Account Manager"
  │   ├─ Use Case 1: "Login with email/password"
  │   └─ Use Case 2: "Login with Google OAuth2"
  │
  ├─ REQ-002: "View Account List"
  │   ├─ Persona: "Account Manager"
  │   ├─ Use Case 1: "Filter accounts by status"
  │   └─ Use Case 2: "Sort by last activity"
  │
  └─ REQ-003: "Export Account Data"
      ├─ Persona: "Account Manager"
      ├─ Use Case 1: "Export as CSV"
      └─ Use Case 2: "Export as Excel"

This complete traceability ensures every deployed capability can be traced from business value (persona needs) → specification (requirements) → acceptance criteria (use cases) → implementation workflow (process).

Next Steps

Now that you understand processes, explore how to:

• Define Requirements - Create capabilities that processes orchestrate
• Manage Teams - Assign accountability and track team performance

Pro Tip: Start with one high-frequency workflow. Build a detailed template with 10-15 requirements, deploy it successfully, then clone for the next 5 projects. You’ll recover the template investment immediately and compound savings over time.

Support

Questions about processes? We’re here to help:

• Documentation: Continue reading about Teams and Deployment Tracking
• In-App Help: Look for the 🤖 AI assistant in the processes interface
• Email: support@catalio.com
• Community: Share process templates and best practices with other Catalio users