Deploying and Scheduling Workflows

Deploy workflows to production, configure automated schedules, and manage deployment lifecycles across environments.

Move your workflows from design to production with confidence. FlowGenX provides enterprise-grade deployment capabilities, flexible scheduling options, and comprehensive monitoring to ensure your automation runs reliably at scale.

Production-Ready Deployment

Deploy, schedule, and monitor workflows with enterprise reliability and control.

Multi

Environments

Trigger Types

Cron

Scheduling

100%

Traceability

Workflow Lifecycle

Understanding the workflow lifecycle helps you move from design to production smoothly:

Design & Build

Create workflows in the Workflow Canvas with visual node editor

Test & Validate

Run test executions, inspect results, and debug with replay mode

Deploy to Environment

Publish workflow to development, staging, or production environment

Monitor & Maintain

Track executions, analyze performance, and optimize over time

Deploying Workflows

Understanding Deployment

Deploying a workflow means making it available for execution in a target environment. Deployed workflows can be triggered manually, via webhooks, on schedules, or by events.

Workflow States:

Draft: Being designed in Workflow Canvas (not executable)
Published: Deployed and available for execution
Active: Currently enabled and can be triggered
Paused: Deployed but temporarily disabled
Archived: Historical version preserved for audit

Deployment Process

Step 1: Prepare for Deployment

Pre-Deployment Checklist:

Workflow Validation

✓ All nodes properly configured
✓ No validation errors in canvas
✓ Required connections established
✓ Trigger node configured

Testing Complete

✓ Test runs executed successfully
✓ Edge cases validated
✓ Error handling tested
✓ Output data verified

Environment Setup

✓ Environment variables configured
✓ Secrets and credentials stored
✓ Integrations connected
✓ Runtime capacity verified

Documentation

✓ Workflow purpose documented
✓ Input/output schemas defined
✓ Dependencies listed
✓ Monitoring plan established

Step 2: Publish Workflow

From the Workflow Canvas:

Save Changes: Ensure all workflow changes are saved
Click "Publish": Located in the top toolbar
Select Target Environment:
- Development (for continued testing)
- Staging (for pre-production validation)
- Production (for live execution)
Configure Deployment:
- Version tag (optional, e.g., "v1.2.0", "2024-01-05")
- Release notes (describe changes)
- Environment-specific variables
Review & Confirm: Check deployment summary
Deploy: Workflow is published to selected environment

Deployment Confirmation:

✅ Workflow "Customer Onboarding" deployed successfully
   Environment: Production
   Version: v1.2.0
   Deployed at: 2024-01-05 10:30 AM UTC
   Webhook URL: https://api.flowgenx.ai/webhook/abc123xyz
   Status: Active

Step 3: Verify Deployment

After publishing:

Navigate to "Event Driven Workflows" section
Filter by environment to see deployed workflow
Check status - should show "Active" or "Ready"
Test trigger - Execute once to verify deployment
View execution in traceability logs
Monitor for errors in first few executions

Trigger Types & Configuration

Workflows can be triggered in multiple ways. Choose the trigger type that matches your use case.

1. Manual Trigger

Purpose: On-demand execution initiated by users or API calls

Use Cases:

Ad-hoc processing tasks
Testing and debugging
Admin operations
User-initiated actions

Configuration:

{
  "type": "manual",
  "inputSchema": {
    "customerId": {
      "type": "string",
      "required": true,
      "description": "Customer ID to process"
    },
    "action": {
      "type": "string",
      "enum": ["activate", "deactivate", "update"],
      "required": true,
      "description": "Action to perform"
    },
    "priority": {
      "type": "number",
      "default": 5,
      "min": 1,
      "max": 10
    }
  }
}

How to Trigger:

Via UI:

Navigate to workflow in dashboard
Click "Run Workflow" button
Fill in required input fields
Click "Execute"

Via API:

curl -X POST https://api.flowgenx.ai/v1/workflows/run \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflowId": "workflow_123",
    "input": {
      "customerId": "cust_456",
      "action": "activate",
      "priority": 8
    }
  }'

2. Webhook Trigger

Purpose: HTTP endpoint that triggers workflow when called by external systems

Use Cases:

API integrations
Third-party service callbacks
Form submissions
Payment notifications
Git push events

Configuration:

{
  "type": "webhook",
  "method": ["POST", "PUT"],
  "authentication": {
    "type": "api_key",
    "header": "X-API-Key",
    "key": "{{ vars.webhook_api_key }}"
  },
  "responseMode": "immediate",  // or "lastNode"
  "timeout": 30000,
  "cors": {
    "enabled": true,
    "allowedOrigins": ["https://app.example.com"]
  }
}

Configuration Options:

Option	Description	Values
method	Allowed HTTP methods	GET, POST, PUT, DELETE, PATCH
authentication	Security mechanism	none, api_key, bearer, hmac, oauth
responseMode	When to respond	immediate (200 OK), lastNode (workflow output)
timeout	Max execution time (ms)	1000 - 300000 (5 minutes max)
cors	Cross-origin configuration	enabled, allowedOrigins, allowedMethods

Generated Webhook URL:

https://api.flowgenx.ai/webhook/abc123xyz

Example Request:

curl -X POST https://api.flowgenx.ai/webhook/abc123xyz \
  -H "Content-Type: application/json" \
  -H "X-API-Key: your_webhook_key" \
  -d '{
    "orderId": "12345",
    "amount": 99.99,
    "currency": "USD"
  }'

Response (Immediate Mode):

{
  "status": "accepted",
  "executionId": "exec_789",
  "message": "Workflow triggered successfully"
}

Response (Last Node Mode):

{
  "status": "completed",
  "executionId": "exec_789",
  "data": {
    "processedOrder": "12345",
    "invoiceId": "INV-456",
    "status": "completed"
  }
}

3. Schedule Trigger

Purpose: Execute workflow automatically on a recurring schedule

Use Cases:

Daily reports
Periodic data synchronization
Nightly batch processing
Weekly summaries
Monthly invoicing

Configuration:

{
  "type": "schedule",
  "cron": "0 9 * * 1-5",  // 9 AM weekdays
  "timezone": "America/New_York",
  "enabled": true,
  "metadata": {
    "description": "Daily morning report generation"
  }
}

Cron Expression Format

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of week (0 - 6) (Sunday=0)
│ │ │ │ │
* * * * *

Common Schedule Patterns

Schedule	Cron Expression	Description
Every minute	* * * * *	Runs every 60 seconds
Every 5 minutes	/5 * * *	Runs at :00, :05, :10, etc.
Every hour	0 * * * *	Runs at the top of each hour
Daily at midnight	0 0 * * *	12:00 AM every day
Daily at 9 AM	0 9 * * *	9:00 AM every day
Weekdays at 9 AM	0 9 * * 1-5	Monday through Friday
Weekly on Monday	0 0 * * 1	Every Monday at midnight
First of month	0 0 1 * *	First day of each month
Every 6 hours	0 /6 * *	12 AM, 6 AM, 12 PM, 6 PM
Business hours	0 9-17 * * 1-5	Every hour 9 AM-5 PM weekdays

Timezone Considerations

Why Timezone Matters:

Schedule executes in specified timezone
Handles daylight saving time automatically
Critical for global operations

Timezone Examples:

{
  "cron": "0 9 * * *",
  "timezone": "America/New_York"    // 9 AM Eastern Time
}

{
  "cron": "0 9 * * *",
  "timezone": "Europe/London"       // 9 AM London Time
}

{
  "cron": "0 9 * * *",
  "timezone": "Asia/Tokyo"          // 9 AM Japan Time
}

{
  "cron": "0 9 * * *",
  "timezone": "UTC"                 // 9 AM UTC (no DST)
}

Managing Schedules

Enable Schedule:

// In workflow configuration
{
  "schedule": {
    "enabled": true
  }
}

Pause Schedule (without deleting):

{
  "schedule": {
    "enabled": false  // Keeps configuration, stops execution
  }
}

Update Schedule:

Edit workflow in Workflow Canvas
Update Schedule Trigger node
Save and re-publish
Schedule updates immediately

Delete Schedule:

Remove Schedule Trigger node from workflow
Re-publish workflow
Schedule is permanently removed

4. App Event Trigger

Purpose: React to events from SaaS applications (HubSpot, Zendesk, Slack, etc.)

Use Cases:

CRM record changes
Support ticket updates
Chat messages
Document uploads
Status changes

Supported Applications:

HubSpot: Contacts, deals, companies
Zendesk: Tickets, users, organizations
Slack: Messages, reactions, channels
Jira: Issues, projects, sprints
Google Cloud Storage: File events
Zoho: CRM entities

Configuration Process:

Step 1: Select Application

{
  "type": "app_event",
  "app": "hubspot"
}

Step 2: Authentication

{
  "authentication": {
    "apiKey": "{{ vars.hubspot_api_key }}",
    "clientSecret": "{{ vars.hubspot_secret }}",  // For webhook signature
    "portalId": "12345678"
  }
}

Step 3: Select Events

{
  "events": [
    "contact.created",
    "contact.propertyChange",
    "deal.statusChange"
  ],
  "filters": {
    "propertyName": "lifecyclestage",
    "newValue": "customer"
  }
}

Step 4: Automatic Webhook Setup FlowGenX automatically:

Subscribes to application webhook
Configures HMAC signature verification
Registers selected event types
Activates webhook

Step 5: Monitor Events

View live event stream in UI
Inspect webhook payloads
Verify connection status
Test event processing

Example HubSpot Event Payload:

{
  "eventId": "evt_123",
  "eventType": "contact.created",
  "occurredAt": "2024-01-05T10:30:00Z",
  "objectId": 12345,
  "portalId": 987654,
  "properties": {
    "email": "john@example.com",
    "firstname": "John",
    "lastname": "Doe",
    "lifecyclestage": "lead"
  }
}

5. Other Trigger Types

Email Trigger

Purpose: Monitor email inbox and trigger on new messages

{
  "type": "email",
  "connection": "gmail-connection",
  "filters": {
    "from": "*@company.com",
    "subject": { "contains": "urgent" },
    "hasAttachments": true
  },
  "pollInterval": "5m"
}

Use Cases: Support ticket creation, invoice processing, document workflows

Database Trigger

Purpose: React to database changes (INSERT, UPDATE, DELETE)

{
  "type": "database",
  "connection": "postgres-prod",
  "table": "orders",
  "events": ["INSERT", "UPDATE"],
  "columns": ["status", "amount"],
  "filter": "status = 'pending' AND amount > 1000"
}

Use Cases: Real-time data processing, change data capture, audit logging

File Trigger

Purpose: Monitor file storage for new or modified files

{
  "type": "file",
  "source": "google-drive",
  "folderId": "abc123",
  "events": ["created", "modified"],
  "fileTypes": ["pdf", "docx", "xlsx"],
  "recursive": true
}

Use Cases: Document processing, file transformation, automated uploads

Message Queue Trigger

Purpose: Process messages from queues (SQS, RabbitMQ, etc.)

{
  "type": "queue",
  "provider": "sqs",
  "queueUrl": "https://sqs.us-east-1.amazonaws.com/123/queue",
  "batchSize": 10,
  "visibilityTimeout": 300
}

Use Cases: Asynchronous processing, event-driven architecture, microservices

Environment Management

Organize workflows across multiple environments for safe development and deployment.

Environment Types

Development

Active development and testing environment

• Frequent deployments
• Test data
• Debugging enabled
• Relaxed rate limits

Staging

Pre-production validation environment

• Production-like setup
• QA testing
• Performance testing
• UAT (User Acceptance)

Production

Live environment serving real users

• Controlled deployments
• Real data
• High availability
• Full monitoring

Environment Variables

Purpose: Store environment-specific configuration without hardcoding

Use Cases:

API endpoints (different URLs per environment)
Database connections
API keys and secrets
Feature flags
Rate limits

Setting Environment Variables:

Navigate to Environment Settings
Select environment (dev, staging, production)
Add variables:

// Development
{
  "API_BASE_URL": "https://api.dev.example.com",
  "DB_CONNECTION": "postgres://dev.db:5432/appdb",
  "FEATURE_NEW_UI": "true",
  "RATE_LIMIT": "1000"
}

// Production
{
  "API_BASE_URL": "https://api.example.com",
  "DB_CONNECTION": "postgres://prod.db:5432/appdb",
  "FEATURE_NEW_UI": "false",
  "RATE_LIMIT": "100"
}

Using in Workflows:

// HTTP Request node
{
  "url": "{{ vars.API_BASE_URL }}/users",
  "headers": {
    "Authorization": "Bearer {{ vars.API_KEY }}"
  }
}

Environment Promotion

Typical Flow: Development → Staging → Production

Promotion Process:

Test in Development
- Validate workflow works correctly
- Test with sample data
- Debug any issues
Promote to Staging
- Deploy same workflow to staging
- Run with production-like data
- Perform UAT (User Acceptance Testing)
- Load/performance testing
Promote to Production
- Schedule deployment window
- Deploy to production
- Monitor closely for first few executions
- Have rollback plan ready

Best Practices:

Always test in lower environments first
Use same version across all environments
Document changes in release notes
Monitor after each promotion
Keep environment variables consistent

Monitoring & Traceability

Event Driven Workflows Dashboard

Access: Navigate to Event Driven Workflows section in Flow Management

Features:

Real-time execution list
Workflow run history
Status indicators
Detailed execution logs
Replay functionality

Workflow Run Details

Each execution shows:

Field	Description
Run ID	Unique identifier for this execution (e.g., exec_abc123)
Workflow Name	Which workflow was executed
Timestamp	When execution started (timezone-aware)
Status	Completed, Failed, In Progress, Pending
Duration	Total execution time
Trigger	What initiated this run (manual, webhook, schedule, event)
Environment	Which environment (dev, staging, production)

Status Indicators

Completed

Execution finished successfully

Failed

Execution encountered errors

In Progress

Currently executing

Pending

Queued, waiting to start

Step-by-Step Inspection

Click on any Run ID to view detailed execution:

Step Details:

Node Name: Which node executed
Status: Success/failure for this step
Input Data: What data the node received
Output Data: What data the node produced
Error Messages: Stack traces if failed
Execution Metadata: Duration, retries, resource usage

Example Step Inspection:

// Step 3: HTTP Request - Fetch Customer Data
{
  "node": "http_request_node_1",
  "status": "completed",
  "duration": 245,

  "input": {
    "customerId": "cust_123",
    "fields": ["name", "email", "plan"]
  },

  "output": {
    "statusCode": 200,
    "data": {
      "id": "cust_123",
      "name": "John Doe",
      "email": "john@example.com",
      "plan": "professional"
    }
  },

  "metadata": {
    "requestTime": 245,
    "retries": 0,
    "cached": false
  }
}

Replay Mode

Purpose: Visualize workflow execution step-by-step

How to Use:

Open any completed execution
Click Replay button
Use controls:
- ← / →: Step backward/forward manually
- ▶: Auto-play execution
- Speed: 0.5x, 1x, 1.5x, 2x playback speed
- Progress: Shows current step (e.g., "Step 3/8")

Benefits:

Understand execution flow visually
Identify bottlenecks (slow steps)
See data transformations
Compare successful vs failed runs
Training and documentation

Filtering & Search

Filter By:

Workflow: Show specific workflow executions
Environment: Development, Staging, Production
Status: Completed, Failed, In Progress
Date Range: Custom time window
Trigger Type: Manual, Webhook, Schedule, Event

Example Filters:

// Show all failed production runs in last 24 hours
{
  "environment": "production",
  "status": "failed",
  "dateRange": "last_24_hours"
}

// Show all webhook-triggered executions
{
  "trigger": "webhook",
  "dateRange": "last_7_days"
}

Version Management & Rollback

Workflow Versions

Every deployment creates a new version:

Version Information:

Version Number: Auto-incremented (v1, v2, v3) or custom tag
Deployed At: Timestamp
Deployed By: User who published
Release Notes: Change description
Git Commit: If integrated with version control

Version History:

v3  2024-01-05 10:30 AM  alice@company.com  "Add retry logic to API calls"
v2  2024-01-04 02:15 PM  bob@company.com    "Fix error handling in payment step"
v1  2024-01-03 09:00 AM  alice@company.com  "Initial production deployment"

Rollback Procedure

When to Rollback:

New version causing errors
Performance degradation
Unexpected behavior
Critical bug discovered

Rollback Steps:

Navigate to Workflow Versions
Identify Last Known Good Version (e.g., v2)
Click "Rollback to v2"

Confirm Rollback:

⚠️ Rollback Confirmation

This will revert "Customer Onboarding" to version v2
Current: v3 (deployed 2 hours ago)
Target:  v2 (deployed yesterday)

Environment: Production
Active executions: 0

[Cancel]  [Confirm Rollback]

Verify: Test workflow after rollback
Monitor: Watch for successful executions

Rollback Effects:

Workflow immediately uses previous version
In-flight executions complete with current version
New executions use rolled-back version
Webhook URLs remain unchanged
Schedules continue uninterrupted

Rollback Considerations

• Rollback is immediate - no gradual transition
• Database schema changes may not revert automatically
• External integrations may need manual cleanup
• Always test rolled-back version before high-traffic periods
• Document rollback reason for team awareness

Deployment Best Practices

Pre-Deployment

Pre-Deployment Checklist

✅ Test thoroughly: Run multiple test executions with various inputs
✅ Validate error handling: Test failure scenarios and retries
✅ Check dependencies: Ensure all integrations and connections work
✅ Review environment variables: Correct values for target environment
✅ Document changes: Write clear release notes
✅ Plan monitoring: Know what metrics to watch post-deployment
✅ Communicate: Notify team of deployment schedule
✅ Prepare rollback: Have previous version ready to restore

During Deployment

Timing Considerations:

Deploy during low-traffic periods
Avoid deployments before weekends/holidays
Schedule staging deployments before production
Allow time for monitoring after deployment

Deployment Windows:

✅ Good Times:
- Tuesday-Thursday, 10 AM - 2 PM (off-peak)
- After business hours for critical systems
- During scheduled maintenance windows

❌ Avoid:
- Monday mornings (high traffic)
- Friday afternoons (limited support availability)
- Before major events/holidays
- During known peak usage times

Post-Deployment

Monitoring Checklist (First 24 Hours):

Immediate (First Hour):
- ✓ First 5 executions complete successfully
- ✓ No error spikes in logs
- ✓ Response times within expected range
- ✓ Webhook endpoints responding
Short Term (2-6 Hours):
- ✓ Execution volume matches expectations
- ✓ Success rate > 95%
- ✓ No unusual patterns in data
- ✓ Downstream systems healthy
Medium Term (6-24 Hours):
- ✓ Performance stable
- ✓ No customer complaints
- ✓ Resource usage normal
- ✓ Costs within budget

Red Flags (Trigger Rollback):

Error rate > 10%
Execution time doubled
Downstream system failures
Data corruption detected
Critical customer impact

Deployment Strategies

1. All-at-Once Deployment

Method: Deploy new version to all instances simultaneously

Pros:

Simple and fast
No version conflicts
Immediate rollout

Cons:

Higher risk
All users affected by issues
No gradual validation

Best For: Low-risk changes, small user bases, staging environments

2. Blue-Green Deployment

Method: Run two identical environments, switch traffic between them

Current (Blue):  [v1] ←── 100% traffic
New (Green):     [v2] ←── 0% traffic (testing)

After validation:
Blue:            [v1] ←── 0% traffic (standby)
Green:           [v2] ←── 100% traffic

Pros:

Zero downtime
Easy rollback (switch back)
Full production testing before cutover

Cons:

Requires double resources
More complex infrastructure
Database synchronization challenges

Best For: Critical workflows, large deployments, high-availability requirements

3. Canary Deployment

Method: Gradually roll out to small percentage of users first

Phase 1: [v2] ←── 5% traffic    [v1] ←── 95% traffic
Phase 2: [v2] ←── 25% traffic   [v1] ←── 75% traffic
Phase 3: [v2] ←── 50% traffic   [v1] ←── 50% traffic
Phase 4: [v2] ←── 100% traffic  [v1] ←── 0% traffic

Pros:

Gradual validation
Limited blast radius
Real-world testing with subset
Easy to abort if issues found

Cons:

Slower rollout
Two versions running simultaneously
More complex monitoring

Best For: High-risk changes, large user bases, gradual rollouts

CI/CD Integration

API-Based Deployment

FlowGenX provides APIs for automated deployment:

Workflow Deployment API:

# Deploy workflow to environment
curl -X POST https://api.flowgenx.ai/v1/workflows/deploy \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflowId": "workflow_123",
    "environment": "production",
    "version": "v1.2.0",
    "releaseNotes": "Add retry logic to API calls",
    "autoActivate": true
  }'

Response:

{
  "deploymentId": "deploy_789",
  "workflowId": "workflow_123",
  "environment": "production",
  "version": "v1.2.0",
  "status": "deployed",
  "deployedAt": "2024-01-05T10:30:00Z",
  "webhookUrl": "https://api.flowgenx.ai/webhook/abc123"
}

GitHub Actions Example

# .github/workflows/deploy-workflow.yml
name: Deploy FlowGenX Workflow

on:
  push:
    branches: [main]
    paths:
      - 'workflows/**'

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Deploy to staging
        run: |
          curl -X POST https://api.flowgenx.ai/v1/workflows/deploy \
            -H "Authorization: Bearer ${{ secrets.FLOWGENX_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{
              "workflowId": "${{ secrets.WORKFLOW_ID }}",
              "environment": "staging",
              "version": "${{ github.sha }}",
              "releaseNotes": "${{ github.event.head_commit.message }}"
            }'

      - name: Run integration tests
        run: npm run test:integration

      - name: Deploy to production
        if: success()
        run: |
          curl -X POST https://api.flowgenx.ai/v1/workflows/deploy \
            -H "Authorization: Bearer ${{ secrets.FLOWGENX_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{
              "workflowId": "${{ secrets.WORKFLOW_ID }}",
              "environment": "production",
              "version": "${{ github.sha }}",
              "releaseNotes": "${{ github.event.head_commit.message }}"
            }'

GitLab CI Example

# .gitlab-ci.yml
stages:
  - test
  - deploy-staging
  - deploy-production

test:
  stage: test
  script:
    - npm run test

deploy-staging:
  stage: deploy-staging
  script:
    - |
      curl -X POST https://api.flowgenx.ai/v1/workflows/deploy \
        -H "Authorization: Bearer $FLOWGENX_API_KEY" \
        -H "Content-Type: application/json" \
        -d "{
          \"workflowId\": \"$WORKFLOW_ID\",
          \"environment\": \"staging\",
          \"version\": \"$CI_COMMIT_SHORT_SHA\",
          \"releaseNotes\": \"$CI_COMMIT_MESSAGE\"
        }"
  only:
    - develop

deploy-production:
  stage: deploy-production
  script:
    - |
      curl -X POST https://api.flowgenx.ai/v1/workflows/deploy \
        -H "Authorization: Bearer $FLOWGENX_API_KEY" \
        -H "Content-Type: application/json" \
        -d "{
          \"workflowId\": \"$WORKFLOW_ID\",
          \"environment\": \"production\",
          \"version\": \"$CI_COMMIT_SHORT_SHA\",
          \"releaseNotes\": \"$CI_COMMIT_MESSAGE\"
        }"
  only:
    - main
  when: manual

Infrastructure as Code

Docker Deployment:

# Deploy FlowGenX runtime agent
docker run -d \
  --name flowgenx-agent \
  -e FLOWGENX_API_KEY=$API_KEY \
  -e FLOWGENX_ENVIRONMENT=production \
  -e FLOWGENX_WORKER_COUNT=4 \
  -v /var/flowgenx:/data \
  flowgenx/runtime-agent:latest

Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flowgenx-runtime
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: flowgenx-runtime
  template:
    metadata:
      labels:
        app: flowgenx-runtime
    spec:
      containers:
      - name: runtime-agent
        image: flowgenx/runtime-agent:latest
        env:
        - name: FLOWGENX_API_KEY
          valueFrom:
            secretKeyRef:
              name: flowgenx-secrets
              key: api-key
        - name: FLOWGENX_ENVIRONMENT
          value: "production"
        - name: FLOWGENX_WORKER_COUNT
          value: "4"
        resources:
          requests:
            memory: "2Gi"
            cpu: "1"
          limits:
            memory: "4Gi"
            cpu: "2"

Helm Chart:

# Install FlowGenX runtime using Helm
helm repo add flowgenx https://charts.flowgenx.ai
helm repo update

helm install flowgenx-runtime flowgenx/runtime-agent \
  --namespace production \
  --create-namespace \
  --set apiKey=$FLOWGENX_API_KEY \
  --set environment=production \
  --set workers.replicas=3 \
  --set resources.requests.memory=2Gi \
  --set resources.requests.cpu=1

Troubleshooting Deployment Issues

Common Issues

Issue: Workflow won't deploy

Symptoms: Deployment fails, error message shown

Common Causes:

Validation errors in workflow (unconfigured nodes)
Missing required environment variables
Invalid trigger configuration
Disconnected integration credentials

Solution:

Open workflow in canvas, check for red error indicators
Verify all required fields are filled
Test workflow locally before deploying
Check environment variable spelling and values

Issue: Schedule not triggering

Symptoms: Workflow deployed but not executing on schedule

Common Causes:

Schedule is disabled (enabled: false)
Incorrect cron expression
Wrong timezone configuration
Workflow is paused

Solution:

Check schedule enabled status in workflow settings
Validate cron expression using online tools
Verify timezone matches intended execution time
Check workflow status is "Active" not "Paused"
Review Event Driven Workflows for any execution attempts

Issue: Webhook returns 404 or 401

Symptoms: Webhook calls fail with authentication or not found errors

Common Causes:

Incorrect webhook URL
Missing or invalid API key
Workflow not deployed to correct environment
Webhook authentication misconfigured

Solution:

Copy webhook URL from workflow deployment confirmation
Verify API key is included in correct header (e.g., X-API-Key)
Check workflow is deployed and active in target environment
Test webhook with curl to isolate issue

Issue: Workflow executes but fails

Symptoms: Workflow triggers but shows "Failed" status

Common Causes:

API credentials invalid or expired
Network connectivity issues
Timeout exceeded
Invalid data format or schema mismatch

Solution:

Open Run ID in Event Driven Workflows section
Identify which step failed
Read error message and stack trace
Use Replay mode to see data flow
Fix issue and redeploy or rollback

Issue: Environment variables not working

Symptoms: Variables show as undefined or empty in workflow execution

Common Causes:

Variables not set in target environment
Typo in variable name
Incorrect expression syntax
Variable not marked as available to workflow

Solution:

Navigate to Environment Settings for target environment
Verify variable exists with correct name (case-sensitive)
Use correct syntax: {{ vars.VARIABLE_NAME }}
Redeploy workflow after adding/updating variables

Security Considerations

Secrets Management

Best Practices:

Secure Credential Storage

✅ Store in environment variables: Never hardcode API keys in workflows
✅ Use expression syntax: {{ vars.API_KEY }} keeps secrets out of workflow definition
✅ Encrypt at rest: FlowGenX automatically encrypts all environment variables
✅ Rotate regularly: Change API keys and secrets on schedule
✅ Principle of least privilege: Only grant minimum required permissions
✅ Separate by environment: Different credentials for dev/staging/production
✅ Audit access: Monitor who accesses secrets and when

Webhook Security

Authentication Methods:

API Key Authentication (Recommended):

{
  "authentication": {
    "type": "api_key",
    "header": "X-API-Key",
    "key": "{{ vars.webhook_secret }}"
  }
}

HMAC Signature Verification (Highest Security):

{
  "authentication": {
    "type": "hmac",
    "algorithm": "sha256",
    "header": "X-Signature",
    "secret": "{{ vars.webhook_signing_secret }}"
  }
}

Bearer Token:

{
  "authentication": {
    "type": "bearer",
    "token": "{{ vars.webhook_bearer_token }}"
  }
}

Network Security

For Hybrid Deployment:

Only outbound connections required (no inbound firewall rules)
TLS 1.2+ for all connections
Certificate pinning supported
IP allowlisting available

Webhook Endpoints:

HTTPS only (no HTTP)
Rate limiting (prevent abuse)
Request size limits
CORS configuration for browser requests

Best Practices Summary

Deployment

✅ Test thoroughly in development first
✅ Always deploy to staging before production
✅ Use version tags for tracking
✅ Write meaningful release notes
✅ Deploy during low-traffic windows
✅ Monitor closely after deployment

Scheduling

✅ Use appropriate schedule frequency
✅ Set correct timezone for global operations
✅ Test schedule with manual trigger first
✅ Document schedule purpose
✅ Monitor schedule execution success rate
✅ Use pause instead of delete when temporarily stopping

Monitoring

✅ Review execution logs regularly
✅ Set up alerts for failures
✅ Use Replay mode for debugging
✅ Track performance trends over time
✅ Filter by environment to isolate issues
✅ Document common failure patterns

Security

✅ Never hardcode credentials
✅ Use environment variables for secrets
✅ Enable webhook authentication
✅ Rotate API keys regularly
✅ Separate credentials by environment
✅ Audit access to sensitive workflows

Next Steps

Environments

Manage development, staging, and production environments

Traceability

Deep dive into execution logs and replay features

Debugging & Testing

Learn how to test and debug workflows effectively

Hybrid Deployment

Deploy runtime agents in your own infrastructure

Ready to deploy? Start with a simple workflow, test it thoroughly in development, then progressively deploy through staging to production. Monitor closely and don't hesitate to rollback if issues arise. Successful deployment is about preparation, monitoring, and having a solid rollback plan.

Deploying and Scheduling Workflows

Production-Ready Deployment

Design & Build

Test & Validate

Deploy to Environment

Monitor & Maintain

Workflow Validation

Testing Complete

Environment Setup

Documentation

Development

Staging

Production

Rollback Considerations

Pre-Deployment Checklist

Issue: Workflow won't deploy

Issue: Schedule not triggering

Issue: Webhook returns 404 or 401

Issue: Workflow executes but fails

Issue: Environment variables not working

Secure Credential Storage

Deployment

Scheduling

Monitoring

Security

Environments

Traceability

Debugging & Testing

Hybrid Deployment

On this page

Ask AI

How can I help you?