Book a demo
opsintermediate12 min setupby Mantle

Salesforce case to a Jira issue

Every new Salesforce case is raised as a Jira issue so engineering works from one queue.

Request this template in a demoTalk to sales
New caseRaise the issue

Drag to pan, pinch to zoom. This is the real graph the template installs.

Purpose

Every new Salesforce case is raised as a Jira issue so engineering works from one queue.

How it works

What it does

  • Polls Salesforce every five minutes for new high-priority Case records.
  • Creates a Jira issue whose summary carries the case number so the two stay findable.

Validation

This template is contract-validated: the unit suite checks every node type, every config key and the whole graph against the same rules a saved workflow passes. It has not been run against the live provider — the ids, names and columns below are placeholders to replace with your own.

Nodes 2

  1. 01New casetrigger.salesforce_eventTrigger
  2. 02Raise the issuejira.create_issueApp
View template JSON
{
  "format": "mantle-workflow/v1",
  "id": "salesforce-case-to-jira",
  "name": "Salesforce case to a Jira issue",
  "graph": {
    "nodes": [
      {
        "id": "case",
        "type": "trigger.salesforce_event",
        "label": "New case",
        "config": {
          "object_name": "Case",
          "mode": "created",
          "fields": "Id, CaseNumber, Subject, Description, Priority, Status",
          "where_clause": "Priority = 'High'",
          "poll_interval_sec": 300
        },
        "worker_type": "generic-worker",
        "position": {
          "x": 60,
          "y": 220
        }
      },
      {
        "id": "issue",
        "type": "jira.create_issue",
        "label": "Raise the issue",
        "config": {
          "project_key": "ENG",
          "issue_type": "Bug",
          "summary": "[{{ $json.record.CaseNumber }}] {{ $json.record.Subject }}",
          "description": "{{ $json.record.Description }}\n\nSalesforce case {{ $json.record_id }} · priority {{ $json.record.Priority }}."
        },
        "worker_type": "generic-worker",
        "position": {
          "x": 380,
          "y": 220
        }
      }
    ],
    "edges": [
      {
        "from": "case",
        "to": "issue"
      }
    ]
  }
}

Requirements

The connections and permissions each step needs, from the node contracts in the catalog.

  • SalesforceOAuth 2.0

    Used by New case.

    Credential: {"client_id", "client_secret", "refresh_token"}

    • This polls SOQL — it is not the Streaming or Pub/Sub API. Salesforce's push mechanisms need a process holding a long-lived subscription, which Mantle has no role for, so latency is up to one poll interval (30 s minimum).
    • The poll reads current state, not a change log: a field changed and changed back within one interval is seen once, at its final value.
    • SystemModstamp also moves for system writes (roll-up recalculations, archive jobs), so `updated` can fire without a person having edited the record.
    • Existing records are never replayed: the first poll only sets the cursor to the org's newest SystemModstamp.
    • Bulk updates share one millisecond; the cursor keeps the ids at its instant so none of them is dropped. Runs are idempotent per record id + modstamp, so a re-poll of the same change cannot start a second run.
    • `created` is CreatedDate == LastModifiedDate. A record created and edited between two polls arrives once, as an update.
  • JiraUsername & password

    Used by Raise the issue.

    Credential: {"email", "api_token"}

Setup

  • Change where_clause for your escalation rule, or delete it to raise an issue for every case.
  • Set project_key and issue_type to a project and type that exist in your Jira.
  • Pick Salesforce and Jira connections.

Sample input and output

Synthetic examples: node-contract samples or placeholders, never customer data.

Input

What the New case trigger receives, as its node contract samples it.

{
  "created": false,
  "object_name": "Lead",
  "record": {},
  "record_id": "00Q5f000004abcEAA",
  "system_modstamp": ""
}

Output

Raise the issue jira.create_issue

{
  "issue_key": "",
  "ok": false,
  "url": ""
}

Failure handling

What the graph does when a step fails, read from its retry settings, error branches and error policies.

  • A step that fails, after any retries, fails the run. The failed step is kept with its input and error.

See it run, then make it yours.

Templates install as drafts. Edit any step, and Workflow Health re-checks the graph on every save.

Book a technical demoTalk to sales