Factories > Factory configuration

Factory automations

Configure factory automations with triggers and filters to control which events start runs and which agent handles the work.

An automation starts factory runs from a trigger and routes them to an agent. Filters narrow which events start work. For example, an automation can send newly opened pull requests to a review agent, but only for one repository’s main branch.

How matching works

An event starts an automation only when it matches the trigger’s provider, event type, and filters:

Every filter must match - A trigger that sets both a team and a label matches only events carrying both.
Any included value can match - A Labels filter listing bug and regression matches an issue with either label.
Empty optional list filters don’t restrict matching - Provider defaults still apply: GitHub triggers skip bot events by default, with skip_bots set to all when omitted.

One event can match more than one automation, and each match starts its own run. If a single action starts duplicate runs, narrow or remove one of the overlapping triggers.

Filters don’t control access

Filters decide when work starts, not what an integration or running agent can access. To change an integration’s access, change its permissions with the provider, not its filters.

Provider account requirements still apply. See who can start work in Slack and account linking in Microsoft Teams. Custom webhooks instead authenticate deliveries with a token or signature; filters aren’t a substitute for that authentication.

What each source can filter on

The table summarizes filter categories. Each linked integration guide lists the filters available for each event type.

Source	Filters
Slack	Conversations, people, keywords, and emoji
Microsoft Teams	Team, channels, authors, and keywords
GitHub	Repository, branches, paths, labels, people, reviews, and workflow results
GitLab	Project, actions, and base branch
Azure DevOps	Repository, branches, work item types, labels, and people
Linear	Team, project, issue, labels, workflow state, and people
Jira	Projects
Custom webhooks	Webhook and JSON payload

For webhook pattern syntax, see Payload filters for webhook triggers.

Edit filters on an automation

You can edit custom automations and the defaults Warp creates when you connect a provider. If your definition lives in an external repository, the Automations page is read-only; edit the definition files instead.

To edit an existing automation’s filters:

In the web app sidebar, expand your factory and click Automations.
Click the name of the automation you want to edit to open its settings.
In the “Triggers” section, adjust the filters for the relevant trigger. Click More filters for additional options.
Click Save in the top-right corner.
Send a matching test event, such as opening a test issue, and confirm that a work item appears in the factory dashboard.

Filters in definitions as code

In a factory definition, an automation’s triggers entries declare the provider, event, and filters. Start with the labeled-issue example, then look up supported keys in the trigger filter reference.

This example reviews pull requests in acme/api-service targeting main, excluding those labeled wip:

---
enabled: true
agent: foreman
triggers:
  - provider: github
    event: pull_request_opened
    filter:
      repos: [acme/api-service]
      base_branches: [main]
      labels:
        not_in: [wip]
---
A pull request was opened against the default branch. If it is a draft,
stop silently. Otherwise review it and post your findings and verdict on
the PR.

Plain lists include matching values; not_in excludes them. The same matching rules apply as in the editor. For complete definitions, see 04-code-review-only and 06-common-automations.

Payload filters for webhook triggers

A webhook trigger’s optional payload filter matches the delivery’s JSON body. Each key names a field that must match; an array lists allowed values. Use nested objects for nested fields and in, not_in, or exists for explicit conditions.

This trigger starts a run for opened or reopened pull requests from a GitHub webhook, skipping drafts and bot authors:

triggers:
  - provider: webhook
    event: received
    filter:
      webhook_ids: [WEBHOOK_UID]
      payload:
        action: [opened, reopened]
        pull_request:
          draft: [false]
        sender:
          type:
            not_in: [Bot]

Replace WEBHOOK_UID with the webhook’s UID. For selecting webhooks and testing patterns against stored deliveries, see Add a Webhook trigger to an automation. The definition reference covers the required webhook_ids filter.

Payload filter reference

Values match by type - Strings match exactly and case-sensitively, numbers match numerically (1 equals 1.0), and booleans and null are matchable values.
Missing keys - A missing key fails in and passes not_in. For example, {"env": {"not_in": ["dev"]}} matches a delivery with no env field. A nested pattern object requires its key to be present.
Arrays - For an array of objects, a nested pattern matches if any element matches. For an array of scalars, in matches on any overlap and not_in requires none.
Combined operators - Operators on the same field must all match. For example, combining in and exists: true requires both to hold.
Limits - A pattern nests up to 10 levels deep, holds up to 64 leaf fields, and lists up to 32 values per set.
Validation - Warp rejects a pattern that lists the same value in both in and not_in on one field, or that combines exists: false with a non-empty in.
Fail closed - A filter that can’t be evaluated never matches.

Troubleshooting

An event doesn’t start work - Follow the factory troubleshooting checklist to check the automation, connection, access, and filters, then inspect any existing work item.
A webhook delivery doesn’t start work - Open the delivery in the webhook’s Recent deliveries to confirm it was accepted rather than rejected or deduplicated, then use Test filter on the automation’s Webhook trigger against that delivery. See troubleshooting custom webhooks.

Connect your factory - Set up sources of factory work
Triggering automations with custom webhooks - Configure senders and authentication
Factory definition syntax - Manage automations as version-controlled files
Factory dashboard - Manage agents, automations, and runs
Scheduled agents - Run standalone cloud agents on a cron schedule outside a factory