Automations

Actions

What an automation agent is allowed to do. Each action declares its required integrations, its compatible triggers, and whether it is high-impact.

An action is a capability the agent can invoke during an automation run. You pick the actions when you build the automation. At run time the agent decides when to use each one and supplies the inputs, such as the pull request title or the issue brief.

Modes

Every action carries a mode that controls when it runs:

always: the action runs every time the automation completes.
smart: the action only runs when the agent judges the execution noteworthy.

Use smart for high-impact actions such as merges and rollbacks, so a routine run does not merge a pull request or roll back a deployment.

Required integrations

Each action declares the integrations it depends on. Connect those first, then the action becomes available in the builder. For example, submitPr requires GitHub, and handoffToDevin requires both Devin and GitHub. The rollback actions declare no integration: they act through the connected cloud account for the target provider.

Actions also declare which triggers they are compatible with. commentPr only accepts pull request and comment events, while the rollback actions accept alerts, cron, webhooks, GitHub events, deployment events, and platform events such as polylane.change_record.created.

Code

Act on pull requests and source branches.

Submit Pull RequestsubmitPr

Runs once per execution after the agent finishes editing and pushes a branch (the agent calls `requestAutomationAction({ actionType: 'submitPr', input: { branch, sha, title, body, ... } })`). The action infers `owner`/`repo` from the triggering GitHub event when not supplied in the input, falls back to the repo's default base branch, and always uses the agent-prepared title and body. Returns the new PR URL and number. With `requireLint: true`, the action fails fast if the agent did not attach a green lint/test artifact, so the agent has to surface CI status before the PR is created.

Requires: github

Comment on Pull RequestcommentPr

Posts a top-level conversation comment via the GitHub Issues comments API on the PR identified by the triggering event. The agent supplies the body via `requestAutomationAction({ actionType: 'commentPr', input: { pullNumber, body } })` and the comment lands as the agent's installed app user. Requires GitHub.

Requires: github

Merge Pull RequestmergePr

Merges the PR identified by the triggering event via the GitHub merge API. The agent supplies the merge method (and optional commit title) via `requestAutomationAction({ actionType: 'mergePr', input: { pullNumber, method } })`. If `method` isn't in `allowedMethods`, the action refuses. With `requireChecks: true`, the action checks the PR's combined status and required checks first and bails out if anything is failing or pending. Requires GitHub.

Requires: github

Autofixautofix

When the automation fires, the agent drafts a step-by-step implementation plan citing file paths and line numbers, then calls `requestAutomationAction({ actionType: 'autofix', input: { title, instructions, owner?, repo?, baseBranch? } })`. The action queues an autofix run with the workspace's default autofix executor (configured in workspace settings): the Polylane agent edits the repo in a sandbox and opens the pull request, or the run is delegated to a connected Devin or Cursor integration which opens the pull request on its own GitHub identity. When the default executor is Devin or Cursor but no matching integration is connected, the run falls back to the Polylane executor.

Requires: github

Hand off to DevinhandoffToDevin

When the automation fires, the agent drafts a step-by-step implementation plan citing file paths and line numbers, then calls `requestAutomationAction({ actionType: 'handoffToDevin', input: { title, instructions, owner?, repo?, baseBranch? } })`. The action queues a Devin session via the workspace's connected Devin integration; Devin clones the repo, applies the plan, runs tests, and opens the pull request on its own GitHub identity. Polylane stays in identify mode and Devin owns implementation. Requires both a connected Devin integration and the target repo indexed in Devin (configured by an admin in `app.devin.ai`). When the repo isn't indexed, the autofix row marks `failed` with `devin_repo_not_indexed` and the workspace's autofix subscribers get an email explaining how to add the repo.

Requires: devin github

Hand off to CursorhandoffToCursor

When the automation fires, the agent drafts a step-by-step implementation plan citing file paths and line numbers, then calls `requestAutomationAction({ actionType: 'handoffToCursor', input: { title, instructions, owner?, repo?, baseBranch? } })`. The action launches a Cursor cloud agent via the workspace's connected Cursor integration; Cursor clones the repo, applies the plan, runs tests, and opens the pull request on its own GitHub identity. Polylane stays in identify mode and Cursor owns implementation. Requires both a connected Cursor integration and the target repo connected to the Cursor account. When the repo isn't connected, the autofix row marks `failed` with `cursor_repo_not_connected` and the workspace's autofix subscribers get an email explaining how to add the repo.

Requires: cursor github

Hand off to FactoryhandoffToFactory

When the automation fires, the agent drafts a step-by-step implementation plan citing file paths and line numbers, then calls `requestAutomationAction({ actionType: 'handoffToFactory', input: { title, instructions, owner?, repo?, baseBranch? } })`. The action provisions a Factory managed computer via the workspace's connected Factory integration, clones the repo onto it, and runs a droid session that applies the plan, runs tests, and pushes a branch; the pull request is opened by the droid or by Polylane from the pushed branch. Polylane stays in identify mode and Factory owns implementation. Requires both a connected Factory integration and the target repo accessible to the Factory organization's GitHub connection. When the computer cannot be provisioned (typically because the repo isn't accessible), the autofix row marks `failed` with `factory_computer_provisioning_failed` and the workspace's autofix subscribers get an email explaining how to connect the repo.

Requires: factory github

Hand off to ConductorhandoffToConductor

When the automation fires, the agent drafts a step-by-step implementation plan citing file paths and line numbers, then calls `requestAutomationAction({ actionType: 'handoffToConductor', input: { title, instructions, owner?, repo?, baseBranch? } })`. The action creates a Conductor cloud workspace via the workspace's connected Conductor integration, clones the repo into it, and runs an agent session that applies the plan, runs tests, and pushes a branch; the pull request is opened by the agent or by Polylane from the pushed branch. Polylane stays in identify mode and Conductor owns implementation. Requires both a connected Conductor integration and the target repo accessible to the Conductor account's GitHub connection. When the workspace cannot be provisioned (typically because the repo isn't accessible), the autofix row marks `failed` with `conductor_workspace_provisioning_failed` and the workspace's autofix subscribers get an email explaining how to connect the repo.

Requires: conductor github

Issue tracking

Open and comment on issues.

Comment on IssuecommentGithubIssue

Posts a comment on the GitHub issue identified by the triggering event. The agent supplies the body via `requestAutomationAction({ actionType: 'commentGithubIssue', input: { issueNumber, body } })`. The comment lands as the agent's installed app user. Requires GitHub.

Requires: github

Create IssuecreateGithubIssue

Opens a new GitHub issue. The agent supplies title, body, optional labels, and optional assignees via `requestAutomationAction({ actionType: 'createGithubIssue', input: { title, body, labels?, assignees? } })`. The action's `defaultLabels` are merged with whatever the agent provides, so you can guarantee every agent-filed issue carries a tag like `agent-generated`. Target repo is inferred from the triggering event when not supplied. Requires GitHub.

Requires: github

Dismiss With CausedismissWithCause

The agent calls `requestAutomationAction({ actionType: 'dismissWithCause', input: { issueId, causeClass, confidence, explanation } })` after concluding the issue does not warrant an incident: noise, a test alert, or a one-off expected behavior. The action sets the issue's status to dismissed, records the cause class and explanation on the issue and its timeline, and stays reversible: a re-fired alert reopens the issue as usual. Low-confidence verdicts are rejected; the agent should explain and ask a human instead.

Flag As ExternalflagExternal

The agent calls `requestAutomationAction({ actionType: 'flagExternal', input: { issueId, externalParty, confidence, explanation, suggestedUpstreamFix? } })` when the investigation shows the alerting service behaves correctly and a specific external caller, client, vendor, or dependency is responsible. The action records the cause on the issue and its timeline, and raises a workspace notification naming the external party with the suggested upstream fix. It never patches the alerting service. Requires high confidence; anything less should explain and ask a human.

Silence Alert RulesilenceAlertRule

The agent calls `requestAutomationAction({ actionType: 'silenceAlertRule', input: { issueId, causeClass, confidence, explanation, scope? } })` for a recurring alert stream established as expected behavior or an external cause. With the default scope alert_rule the action disables automatic triage for the issue's alert rule (the same per-rule toggle exposed in the console, so it is one click to re-enable); with scope fingerprint it suppresses only the issue's exact alert signature, so other alerts from the same rule keep triaging. Either way it records the explanation on the issue timeline, publishes an explanation page, and raises a workspace notification so the silence is never a silent drop. Requires high confidence and a cause of expected_behavior or external_client; anything else is rejected so a real bug cannot be silenced from a weak verdict.

Deployment

Operate on live deployments.

Roll Back Cloudflare DeploymentrollbackCloudflareDeployment

Rolls a Cloudflare Worker version or Pages deployment back. For Workers (versioned), rolls 100% of traffic to the previous version. For Pages, rolls back to the prior deployment. Container deployments are not yet supported and produce a clear failure. When the automation is triggered by a `cloudflare.deployment` event the target resource comes from the event; otherwise the agent names it via `requestAutomationAction({ actionType: 'rollbackCloudflareDeployment', input: { strategy, accountId, resourceType, resourceId } })`, identifying the resource to roll back from its investigation.

Roll Back Vercel DeploymentrollbackVercelDeployment

Rolls back a Vercel project + environment. `redeploy_previous` finds the most recent READY deploy other than the currently-live one and promotes it. `pin_to_deployment` promotes the deployment named in `deploymentId`. Uses Vercel's instant-promote API. When triggered by a `vercel.deployment` event the project/environment come from the event; otherwise the agent names them via `input: { accountId, projectId, environment }`.

Roll Back Render DeploymentrollbackRenderDeployment

Rolls back a Render service. `redeploy_previous` triggers a new deploy of the most recent succeeded commit other than the currently-live one. `pin_to_commit` triggers a deploy at the supplied git commit ID. When triggered by a `render.deployment` event the service comes from the event; otherwise the agent names it via `input: { accountId, serviceId }`.

Roll Back Fly DeploymentrollbackFlyDeployment

Rolls back a Fly app. `redeploy_previous_image` finds the image ref running before the currently-live one across the app's machines and rolls each machine back to it. `pin_to_image` rolls each machine to the supplied image ref. The rollout is sequential per machine with state-polling between machines. When triggered by a `fly.deployment` event the app comes from the event; otherwise the agent names it via `input: { accountId, appId }`.

Notable actions

submitPr opens a pull request from a branch the agent pushed during the run. Set requireLint: true to fail the action unless the agent attached a passing lint or test report.
commentPr, commentIssue, and createIssue post comments and open GitHub issues. createIssue merges your configured defaultLabels into every issue, so you can tag everything the agent files with a label like agent-generated.
mergePr merges the triggering pull request. You constrain it with allowedMethods (merge, squash, or rebase) and requireChecks: true, which refuses to merge while any required check is failing or pending.

Example mergePr config

{ "type": "mergePr", "mode": "smart", "allowedMethods": ["squash"], "requireChecks": true }

Rollbacks

One rollback action exists per deployment provider: rollbackCloudflareDeployment, rollbackVercelDeployment, rollbackRenderDeployment, and rollbackFlyDeployment. Each supports a redeploy-previous strategy that returns to the last known-good version (redeploy_previous, or redeploy_previous_image on Fly), plus a pin strategy that targets a specific version, deployment, commit, or image: pin_to_version on Cloudflare, pin_to_deployment on Vercel, pin_to_commit on Render, and pin_to_image on Fly. When the automation was triggered by a deployment event, the target comes from the event. Otherwise the agent names the resource to roll back from its investigation.

Opening issues

The openIssue action opens a Polylane issue and starts its investigation, subject to the workspace's daily auto-investigation limit. The agent supplies a title, a severity, and a prompt that becomes the investigation's first message. The issue records the automation as its origin and links back to the triggering execution. Set defaultSeverity in the config as a fallback when the agent does not specify one.

Autofix and handoffs

The autofix action queues an autofix run: the agent drafts an implementation plan with file paths and line numbers, and the workspace's default autofix executor implements it and opens a pull request. If the default executor is Devin or Cursor but no matching integration is connected, the run falls back to the Polylane executor.

To pin a specific external agent instead, use handoffToDevin, handoffToCursor, or handoffToFactory. Each delegates implementation to the connected Devin, Cursor, or Factory integration, which clones the repository and applies the plan. Devin and Cursor open the pull request on their own GitHub identity. Factory runs a droid that pushes a branch; the pull request is opened by the droid or by Polylane from that branch. Each handoff action also requires GitHub.

Triggers

The events that start an automation. Platform triggers are always available; provider triggers become available when you connect the provider.

Destinations

Where automation results get delivered. Email, Slack, and webhook destinations, each with an always or smart delivery mode.