Skip to content

Workflows

Workflows are tenant-scoped automations built on a visual canvas. Connect triggers (HubSpot deal closed, Patrol lifecycle events), Patrol actions (find or create customer, create environment), and integration outputs (update HubSpot, create ServiceNow CI) into a single flow.

Integrations are connections only — credentials, field mapping, and event logs live on the integration detail page. Workflows live under Workflows in the sidebar.

  • Integrations feature enabled on your plan
  • At least one connected integration when using integration triggers or outputs

HubSpot deal closed → provision customer

Section titled “HubSpot deal closed → provision customer”
  1. Open Workflows in the sidebar and click New Workflow
  2. From the palette, add Deal closed won (HubSpot trigger)
  3. Select your HubSpot integration in the node properties panel
  4. Add Find or create customer, then Find or create environment (or Run deployment after)
  5. Use the node properties panel to map fields — placeholders show paths like trigger.company.name
  6. Connect the nodes top-to-bottom and click Save

When a matching HubSpot deal closes, Patrol runs the workflow. If no workflow matches, the legacy HubSpot handler still runs automatically.

For a complete node-by-node walkthrough (customer, environment, and deal write-back), see Example — HubSpot deal provisioning.

To push data to external systems when Patrol events occur:

  1. Add a Patrol trigger such as Customer created or Deployment succeeded
  2. Optionally set a service template ID in the trigger node config to scope the workflow
  3. Add integration output nodes (e.g. hubspot:update_company, servicenow:create_ci, servicenow:update_change)
  4. Map fields using paths like customer.id, environment.name, or trigger.dealId

Each node panel shows:

  • This node provides — paths downstream nodes can reference (e.g. customer.id, environment.name)
  • Available from earlier steps — outputs from connected upstream nodes
  • Field mapping — labelled inputs with placeholders showing which path to use

Use paths like trigger.dealId, customer.id, or environment.name. Values without a dot are passed through as literals.

You can also use templates with ${path} placeholders — for example New ${trigger.deal.dealname} env resolves each placeholder from the workflow context and concatenates the result.

ActionDescription
Find or create customerMatch by HubSpot company ID or create new
Find or create environmentMatch by HubSpot deal ID, name, or external ref — create if not found
Find environmentLook up by ID or name within the current customer (fails if missing)
Create environmentRegister a new environment for the customer (fails if name already exists)
Run deploymentTrigger the environment’s configured deployment adapter
Run runbookTrigger a runbook execution with target selector and parameter overrides

HubSpot Update deal and Update company nodes use a fixed ID field plus dynamic property rows. Click Add property for each HubSpot property you want to write:

  • Property name — the HubSpot internal name (e.g. patrol_status, patrol_environment_id)
  • Value — a context path (environment.id), literal (live), or template (Provisioned ${environment.name})

Every property row (except the deal/company ID) is sent to the HubSpot CRM API as a property update.

Continue on error only skips remaining failures — it does not populate context from a failed step. If Create environment fails because the environment already exists, downstream nodes will not have environment.id or environment.name. Use Find or create environment for idempotent HubSpot deal workflows instead.

The workflow editor adapts to smaller screens. On mobile devices:

  • The node palette and node configuration panel are hidden by default, giving the full screen to the canvas.
  • Tap the + floating button (bottom-left) to open the node palette as a bottom sheet. Tapping a node adds it to the canvas and closes the sheet.
  • Tap any node on the canvas to open its configuration panel as a bottom sheet.
  • Deleting nodes — tap a node to select it, then tap the × button that appears on its top-right corner. You can also use the Delete node button at the bottom of the configuration panel.
  • Deleting connections — tap a connection line to select it, then tap the red trash floating button that appears next to the + button.

Open a workflow and switch to the Debug tab to test without side effects. While a debug session is active, a banner appears on the Editor tab with the current status (for example Listening or Ready to step).

  1. Go to the Debug tab and click Listen for trigger — Patrol waits up to 15 minutes for the next matching HubSpot webhook
  2. Send a HubSpot workflow webhook test (or close a deal in a test workflow)
  3. When the trigger arrives, Patrol captures the merged deal/company payload (CRM + webhook) and does not run live actions. The debug panel shows both Captured trigger (merged, for field mapping) and Raw webhook body (exactly what HubSpot sent).
  4. Click Step next node to dry-run each action one at a time
  5. Expand each step in the Execution trace to inspect resolved field mappings and simulated outputs

Dry-run outputs are marked with _dryRun: true. Create/update actions show _wouldCreate or _wouldDeploy instead of writing to Patrol or external systems.

Alternatively, click Pin sample data to paste JSON trigger payload and step through without waiting for HubSpot.

While a workflow is in listen mode, that workflow is excluded from live execution for the captured webhook. Other enabled workflows still run normally.

Switch to the Executions tab to see production runs of the workflow — triggered by HubSpot webhooks or Patrol lifecycle events. Each row shows status, trigger type, summary, duration, and links to any customer or environment created. Expand a row to inspect per-node step results.

Inbound HubSpot webhooks and outbound integration calls still appear under Integrations → Event Log for the relevant integration.