SalesforceLinear

Raise Linear issues from Salesforce cases that need engineering

A Salesforce + Linear agent flow

A support Case in Salesforce gets escalated to engineering, and the handoff is a Slack ping that an engineer maybe sees. Linear is where the dev team's work actually lives, so an escalation that never becomes a Linear issue never gets scheduled. This recipe closes that gap. The agent runs a SOQL query for Cases flagged to engineering since the last run with run_soql_query, then opens a Linear issue per Case with create_issue, carrying the subject, the description, and the Case number. Salesforce answers the query when asked, so the agent runs on a cadence, every few minutes, and a Case it has already escalated, matched by Case number, won't spawn a second issue.

The flow

Salesforcerun_soql_query

Runs a SOQL query against a Salesforce org.

Linearcreate_issue

Creates a new issue or sub-issue with title, description, and workflow metadata.

Step by step

  1. Query escalated cases

    The agent calls run_soql_query for Cases where your escalation flag is set and the modified time is after the last run, selecting subject, description, priority, and case number.

  2. Dedupe by case number

    Before creating, it checks Linear for an issue already carrying that Case number, using list_issues or a search, so a Case that stays open across runs isn't filed twice.

  3. Open the Linear issue

    create_issue makes the issue in the engineering team with the Case subject as the title, the description and priority carried over, and the Salesforce Case number in the body so support and dev share one reference.

Tell your agent

Every five minutes, run my SOQL query for Cases flagged Escalate_to_Engineering changed since the last run, and for each one not already in Linear, create an issue in the Platform team with the subject, description, priority, and the Case number in the body. Match on Case number to avoid duplicates.

Setup

This flow needs both servers connected to your agent. Follow each install guide:

Worth knowing

  • run_soql_query returns only the fields your SELECT lists. Include the Case number and the modified timestamp explicitly, since the agent needs them for dedupe and for advancing its watermark between runs.
  • create_issue maps priority and status to Linear's own scale and workflow states by id. Resolve the team's statuses with list_issue_statuses once and translate Salesforce priority to the matching Linear value, or issues land at a default you didn't intend.
  • Track the last run's high-water mark on the Case LastModifiedDate, not on creation time. A Case escalated days after it opened would be missed if you filter on CreatedDate.

Questions

Can the Linear issue link back to the Case in Salesforce?
Put the Salesforce Case URL in the issue description. The query can return the Case id, and a Salesforce Case URL is a stable pattern of your org domain plus the id, so the agent can construct the link without an extra call.
What about updating the issue when the Case changes?
This flow creates the issue on first escalation. To keep it in sync, a second pass re-queries Cases changed since last run and calls update_issue on the matching Linear issue, found by the stored Case number.