Export formats compared: Torq YAML, Tines story files, ARM templates

A format that round-trips is not a format that travels

Start with a distinction. A platform can export a playbook and import it back, which proves the file works inside one vendor. It says nothing about whether any other vendor reads it. In the data we read on 2026-11-03, no vendor documents an importer for a rival's playbook file. The nearest thing is D3's claim to accept source-native formats, and that is a vendor claim with no technical page behind it.

So read every export format as a backup and a promotion path between your own environments. Use it for migration only after you have confirmed, in writing, that the destination reads it.

Torq writes YAML you can hand edit

Torq exports and imports workflows as YAML. The file holds the structure, description, tags and section. Custom steps and integrations the workflow uses travel in the export package, and the file can be edited directly (Torq knowledge base, export and import workflows) (read 2026-11-03). An import failure is usually a broken manual edit (Torq Learn, import and export workflows) (read 2026-11-03).

On import you pick a conflict rule: keep original, override original or duplicate. Automated imports default to keep original. The public API also imports workflows, and YAML taken from a revision must be escaped, with jsonEscape recommended. We found no native Git sync on the pages read. Torq's migration blog names no converter from another SOAR (Torq blog, 2025-03-24) (read 2026-11-03, vendor claim).

Tines writes JSON and says what it leaves out

Tines exports a story as JSON. The file holds actions with their sources and receivers. It excludes event data, resources and credentials. Export offers options to randomize page and webhook URLs and to clear email addresses and monitoring recipients, and export is also available by API (Tines help, importing and exporting stories) (read 2026-11-03). The docs page, last updated 2026-08-19, describes exporting with no actions selected (Tines docs) (read 2026-11-03).

Import takes the file from the Stories page. A Replace option appears when a story with the same name exists. The help page says there are no version limits and backward compatibility is maintained. The Tines back-up article lists community stories for backing up to GitHub or S3 and says nothing on version history or rollback (Tines help, back up stories) (read 2026-11-03).

The credential exclusion is the point to plan around. After any import, every credential must be re-created. That is correct security design, and it is also a task list.

Sentinel exports ARM, which only Azure reads

A Sentinel playbook is a Logic Apps workflow, and a playbook template is an ARM template with the workflow and its API connections (Microsoft, Automate threat response with playbooks) (read 2026-11-03). The code view exposes ARM JSON. Microsoft advises removing tenant and subscription details, and a script in the Azure-Sentinel repository exports a sanitized template. Automation rules can also be exported as ARM JSON for CI/CD (Microsoft, Automation rules) (read 2026-11-03).

ARM is the best fit for source control and pipeline deployment of the formats here. It is also the most tied to one cloud. API connections in the template point to Azure resources, and nothing outside Azure consumes them.

The rest of the field, one line each

• Splunk SOAR. JSON download of a saved playbook, and a .tgz archive on import into the same or a higher version and the same editor type (Splunk SOAR Cloud export and import) (read 2026-11-03). The page does not explain how the two relate.
• Swimlane. A .ssp solution package, exportable and importable by system administrators only. History, records, key-store secrets and secure asset values are excluded (Swimlane 10x guide) (read 2026-11-03). Swimlane says up to 90 percent of workflows migrate in from other SOARs, with no technical page (Swimlane SOAR migration) (read 2026-11-03, vendor claim).
• Google SecOps SOAR. ZIP files for playbooks and blocks, moved between staging and production, and the system accepts only ZIP on import (Google playbooks screen) (read 2026-11-03).
• Cyware Orchestrate. JSON, or SVG or PNG images for export, and JSON for import. This came from a search summary, because the page fetch returned an empty shell (Cyware Techdocs) (read 2026-11-03, search summary).
• Blink Ops. Every workflow has a YAML representation with name, type, workflow_type, connections and steps. Re-import of YAML is not documented on the page read (Blink docs, workflow YAML) (read 2026-11-03).
• D3 Security. A saved playbook version exports as encrypted XML, YAML or JSON, and Import Playbook takes all three. The guide documents no export to another vendor's format (D3 18.6 guide) (read 2026-11-04).
• Cortex XSOAR. Zip bundles of custom content between XSOAR servers, and a forum report that single playbooks import as YAML with no export. We could not confirm a single-playbook export format for XSOAR 8 (pan.dev export job reference) (read 2026-11-03, search summary).
• ServiceNow. Playbooks are process-based or flow-based, and the official page does not describe transport. A third-party guide describes an XML update set (ServiceNow docs, Security Incident Response playbooks) (read 2026-11-03).
• Mate. No export of a Gamebook is documented, and no Gamebook file format is named. Mate says it translates SOAR playbooks into Gamebooks and validates them before activation, and names no source formats (Mate Gamebooks) (read 2026-11-03, vendor claim).

What the table tells you about buying

Three patterns hold across the list. First, text formats (YAML, JSON, XML) are diffable and belong in Git. Binary or package formats (.ssp, .tgz, ZIP) need a platform to read them. Second, the exclusions differ, and the exclusions are where the work is: credentials at Tines, secrets at Swimlane, event data at Tines, tenant details at Sentinel. Third, a documented importer for a rival's format is rare, and when a seller says it has one, the useful reply is to ask for three things: the file extension, the version, and what fails.

Checklist before you rely on any format

• Export one real playbook from each platform in scope and open the file.
• Record what the file leaves out: credentials, secrets, history, event data.
• Import it into a clean workspace and list what breaks.
• Test the conflict behaviour: replace, keep, duplicate.
• Store text exports in Git and diff two versions.
• Ask any destination that claims an importer for the source file extension and version.
• Ask for the list of what does not port, in writing.
• Re-create credentials from your vault, not from the file.
• Keep an export of every playbook from the old platform until the parallel run ends.