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
| Type | UI Component | Best For | Example |
|---|---|---|---|
text | Text input | Free-form text | Organization ID, project name |
number | Number input | Numeric values | Threshold, limit, count |
boolean | Yes/No dropdown | Toggle flags | Include inactive, strict mode |
select | Single dropdown | Choose one option | Environment, priority |
multi-select | Multi-select dropdown | Choose multiple | Repositories, teams, users |
Text Variables
For: Free-form text input (IDs, names, etc.)Number Variables
For: Numeric values (thresholds, limits, counts)Boolean Variables
For: Yes/No flags, enable/disable optionsSelect Variables
For: Choose one option from a predefined listStatic Options
Dynamic Options (Fetched from API)
- User connects integration
- Platform fetches options using the connection’s credentials
- User sees dropdown populated with real data from their account
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 monitorDefault Values
- Optional settings with sensible defaults
- Advanced options most users don’t change
- Don’t use for required fields
Required vs Optional Variables
Required Variables
- User can’t save without filling this
- Checks won’t auto-run until provided
- Validation error shown if empty
Optional Variables
- User can skip this
- Checks use default value if not set
- Checks auto-run even if not configured
Variable Fetching Context
When usingfetchOptions, you get a limited context:
- 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
required: true- Can’t be emptytype: 'url'- Must be valid URLtype: 'number'- Must be numeric
In the Check
Reusable Variables
Define once, use in multiple checks:- 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
- Required variables are missing → User must configure them
- All variables are optional → Still auto-runs (uses defaults)
- 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

