Skip to main content

Overview

Variables let users configure check behavior without changing code. For example:
  • Which repositories to monitor
  • Which teams to check
  • Severity thresholds
  • Include/exclude flags

Variable Types


Text Variables

For: Free-form text input (IDs, names, etc.)
Access in check:

Number Variables

For: Numeric values (thresholds, limits, counts)
Access in check:

Boolean Variables

For: Yes/No flags, enable/disable options
Renders as: Dropdown with “Yes” / “No” options Access in check:

Select Variables

For: Choose one option from a predefined list

Static Options

Dynamic Options (Fetched from API)

When dynamic options are used:
  1. User connects integration
  2. Platform fetches options using the connection’s credentials
  3. User sees dropdown populated with real data from their account
Access in check:

Multi-Select Variables

For: Choose multiple items from a list (most common for selecting resources)

Static Options

Dynamic Options (Most Common)

Example: Select which GitHub repositories to monitor
Renders as: Multi-select dropdown with search Access in check:

Default Values

Use defaults for:
  • Optional settings with sensible defaults
  • Advanced options most users don’t change
  • Don’t use for required fields

Required vs Optional Variables

Required Variables

Behavior:
  • User can’t save without filling this
  • Checks won’t auto-run until provided
  • Validation error shown if empty
Use for: Essential configuration (IDs, critical settings)

Optional Variables

Behavior:
  • User can skip this
  • Checks use default value if not set
  • Checks auto-run even if not configured
Use for: Advanced settings, filters, optional features

Variable Fetching Context

When using fetchOptions, you get a limited context:
Keep it simple:
  • Fetch a list of resources
  • Map to { value, label } format
  • Don’t fetch large datasets (use pagination)
  • Don’t perform complex logic

Validation

In the Manifest

Built-in validation:
  • required: true - Can’t be empty
  • type: 'url' - Must be valid URL
  • type: 'number' - Must be numeric

In the Check


Reusable Variables

Define once, use in multiple checks:
Benefits:
  • Consistent variable definitions
  • Centralized option fetching
  • Easier maintenance

Auto-Run Behavior

Checks auto-run after connection when:
  • All required variables are configured
  • Connection is active
  • Integration has checks defined
Checks DON’T auto-run when:
  • Required variables are missing → User must configure them
  • All variables are optional → Still auto-runs (uses defaults)
After saving variables:
  • Platform checks if all required variables are now set
  • If yes → Auto-triggers check run via Trigger.dev
  • If no → Waits for remaining variables

Best Practices

Do’s

  • Clear labels: “Organization ID” not “Org ID” not “id”
  • Helpful help text: Explain where to find the value
  • Good placeholders: Show format/example
  • Sensible defaults: For optional settings
  • Required only when truly needed: Don’t over-require

Don’ts

  • Don’t use vague labels: “Setting 1”
  • Don’t skip help text: Users need guidance
  • Don’t make everything required: Only essentials
  • Don’t fetch huge option lists: Paginate or filter
  • Don’t use technical jargon: User-friendly language

Examples from Built-in Integrations

GitHub: Target Repositories

GCP: Organization ID

Linear: Target Teams


Summary

Variables make integrations flexible and user-friendly. Use them to:
  • Let users scope checks to specific resources
  • Configure thresholds and limits
  • Enable/disable features
  • Provide organization-specific context
Keep it simple - only add variables when truly needed for configuration.