Skip to main content

Trigger Types

Triggers define what starts your flow. Every deployed flow needs at least one trigger. FactoryThread supports multiple trigger types for different automation scenarios.

Manual Trigger​

The simplest trigger - runs when you manually execute the flow.

When to Use​

  • Testing and development
  • Ad-hoc data processing
  • One-time migrations
  • User-initiated actions

Configuration​

Manual triggers have minimal configuration:

  • Name (optional) - Descriptive label

Execution​

To run a flow with a manual trigger:

  1. Open the flow in the Designer
  2. Click Preview to test
  3. Or run from the API with your API key

Schedule Trigger​

Runs your flow automatically based on a time schedule.

When to Use​

  • Daily/weekly data synchronization
  • Regular report generation
  • Periodic cleanup tasks
  • Batch processing jobs

Configuration​

Simple Schedules

Quick presets for common patterns:

  • Every 15 minutes
  • Hourly
  • Daily at specific time
  • Weekly on specific day
  • Monthly on specific date

Custom Cron Expression

For advanced scheduling, use cron syntax:

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

Examples:

ScheduleCron Expression
Every hour0 * * * *
Daily at 6 AM0 6 * * *
Monday at 9 AM0 9 * * 1
First day of month0 0 1 * *
Every 30 minutes*/30 * * * *
Weekdays at 8 AM0 8 * * 1-5

Timezone

All schedules run in your workspace's configured timezone. Make sure to account for this when setting schedules.

Viewing Scheduled Runs​

See upcoming scheduled executions:

  • In the Dashboard "Upcoming Schedules" widget
  • In the flow's trigger configuration
  • In the Insights page

Handling Missed Runs​

If a scheduled run is missed (server downtime, etc.):

  • The system does not retroactively run missed schedules
  • The next scheduled run will occur as normal
  • Check Insights for any gaps in execution history

HTTP Trigger​

Exposes your flow as a REST API endpoint that can be called from external systems.

When to Use​

  • Building APIs for external consumption
  • Webhook endpoints for third-party integrations
  • Real-time data requests
  • Synchronous data processing

Configuration​

Endpoint Settings

  • Path - The URL path for your endpoint (auto-generated or custom)
  • Method - HTTP method(s) to accept (GET, POST, etc.)
  • Authentication - Require API key for access

Request Schema

Define the expected input structure:

Query Parameters (for GET requests)

?customerId=123&includeHistory=true

Request Body (for POST/PUT/PATCH)

{
  "customerId": "string",
  "filters": {
    "status": "string",
    "dateFrom": "date"
  }
}

Path Parameters

/api/customers/{customerId}/orders

Using Request Data​

Request parameters are available in your workflow:

  1. Add parameters to your HTTP trigger configuration
  2. Reference them in downstream nodes using ${parameterName}
  3. Use them in filters, transforms, or as input to other nodes

Response Configuration​

Control what's returned:

  1. Add a Response node to your flow
  2. Configure the response data structure
  3. The trigger returns this data to the caller

Response Codes:

  • 200 - Success with data
  • 201 - Created
  • 400 - Bad request (validation failed)
  • 401 - Unauthorized (invalid/missing API key)
  • 500 - Internal error

Example: Customer Lookup API​

  1. HTTP Trigger: GET /api/customers/{id}
  2. Entity node: Load from Customers table
  3. Filter: CustomerID equals ${id}
  4. Response: Return customer fields

Testing HTTP Triggers​

Before sharing with external systems:

  1. Deploy the flow
  2. Copy the endpoint URL
  3. Test with curl, Postman, or your browser
  4. Include your API key in the header: 
    Authorization: Bearer your-api-key

From Flow Trigger​

Creates a reusable flow that can be called by other flows.

When to Use​

  • Shared processing logic
  • Modular workflow design
  • Building libraries of reusable operations
  • Decomposing complex flows

Configuration​

Input Parameters

Define what data the flow expects:

  • Parameter name
  • Data type (text, number, date, etc.)
  • Required or optional
  • Default value

Example Parameters:

customerId: string (required)
startDate: date (optional, default: 30 days ago)
includeInactive: boolean (optional, default: false)

Calling From Other Flows​

To use a flow with From Flow trigger:

  1. In your calling flow, add a Call Flow node
  2. Select the target flow
  3. Map values to the input parameters
  4. The called flow's response becomes available downstream

Return Data​

Use a Response node to define what data is returned to the calling flow.

Best Practices​

Keep Focused Each "From Flow" flow should do one thing well:

  • "Enrich Customer Data"
  • "Calculate Shipping Cost"
  • "Validate Address"

Document Parameters Use clear parameter names and add descriptions.

Handle Errors Return meaningful error information when things go wrong.

Multiple Triggers​

A flow can have multiple triggers of different types.

Use Cases​

  • Schedule AND manual (for testing scheduled flows)
  • Multiple schedules (different frequencies for different needs)
  • HTTP AND From Flow (API and internal use)

Configuration​

  1. Add your primary trigger
  2. Add additional triggers from the Action menu
  3. Each trigger operates independently

Execution Context​

The flow receives context about how it was triggered:

  • Trigger type
  • Input parameters (if applicable)
  • Execution timestamp

Trigger States​

Enabled/Disabled​

Triggers can be enabled or disabled without undeploying the entire flow:

  • Disable a schedule temporarily
  • Keep HTTP endpoint active while testing new schedule

Deployed vs Draft​

  • Draft - Triggers are not active
  • Deployed - Triggers are active and will fire

Best Practices​

Choose the Right Trigger​

ScenarioTrigger Type
Regular data syncSchedule
External APIHTTP
Reusable logicFrom Flow
Ad-hoc processingManual

Schedule Considerations​

  • Avoid scheduling at common times (midnight, top of hour)
  • Stagger multiple schedules to avoid resource contention
  • Consider dependencies between scheduled flows

HTTP Security​

  • Always require API key authentication
  • Use HTTPS (automatic in production)
  • Validate input data thoroughly
  • Log requests for auditing

Testing Triggers​

  1. Start with Manual trigger during development
  2. Test Schedule triggers by checking execution history
  3. Test HTTP triggers with API tools before integration
  4. Test From Flow triggers from a test parent flow

Troubleshooting​

Schedule Not Running​

  • Check the flow is deployed
  • Verify the cron expression is correct
  • Check timezone settings
  • Look for errors in recent execution history

HTTP Returns 401​

  • Verify API key is valid
  • Check Authorization header format
  • Ensure the key has permission for this flow

From Flow Not Found​

  • Check the target flow is deployed
  • Verify the flow ID is correct
  • Ensure you have permission to call the flow

Next Steps​